Кластерный индекс... это на самом деле понятие крайне виртуальное.

Что такое обычный некластерный индекс? берём выражение индекса, считаем его значение для каждой записи, сортируем и пишем на диск. Получаем отдельную структуру, в которой выражение индекса сортировано. Когда потребуется искать заданное значение этого выражения, мы вместо просмотра от записи к записи сразу половинным делением быстренько найдём нужное значение, возьмём из него уникальный идентификатор записи, и обратимся за записью. Если в таблице 1000 записей, то для поиска заданного значения без индекса нам в среднем пришлось бы просмотреть 500 записей, а с индексом - всего 10.

Теперь что такое кластерный индекс... сначала почти то же. Берём выражение индекса, считаем его значение для каждой записи, сортируем и... а вот теперь не записываем по порядку эти значения с номерами соответствующих записей в отдельную структуру, а сами записи располагаем в этом порядке. Теперь, когда потребуется искать заданное значение этого выражения, мы вместо просмотра от записи к записи, как это было, когда записи не сортированы, сразу половинным делением быстренько найдём нужное значение. Но нам уже не надо получать номер записи и обращаться за ней - мы нашли саму нужную запись.

В MySQL (точнее, в используемом по умолчанию движке InnoDB) первичный индекс, во-первых, существует ВСЕГДА, во-вторых, определяется так (в статье, на которую дали ссылку, имеются неточности в пункте 2):

1. Если первичный ключ задан явно, то его выражение является также и выражением кластерного индекса. Или иначе - первичный ключ и есть кластерный индекс.
   
2. Если первичный ключ явно не задан, но в таблице имеется индекс, отвечающий всем следующим требованиям:
   
   • является уникальным
     
   • не является функциональным, в т.ч. не использует в выражении вычисляемые поля
     
   • не использует в выражении поля, которые определены как допускающие значение NULL
     
   
   то именно такой индекс используется в качестве первичного. А если таких индексов несколько, то используется первый по тексту запроса на создание таблицы
   
3. Если не имеется ни того, ни другого - генерируется синтетический скрытый 6-байтовый номер записи, который и используется как первичный ключ. Следует отметить, что штатных способов доступа к этому значению не существует.
   

Выглядит так, как будто это просто физическая сортировка данных по индексируемому полю.

Фактически - именно так.

Создаётся ли отдельная таблица или просто упорядочивается хранение существующих данных?

Не создаётся. Но при изменении первичного индекса таблица полностью пересоздаётся с новым физическим порядком записей.

Если данные упорядочиваются этим индексом, допустим по ID, то почему при select без сортировки данные могут возвращаться в произвольном порядке, а не отсортированные по ID по-умолчанию?

Если не задан явно ORDER BY, сервер имеет право вернуть записи в любом порядке, как ему удобнее. В большинстве случаев, но не всегда, он будет возвращать записи в порядке чтения с диска...

Представь такой (на самом деле невозможный, но не суть) случай - ты запросил таблицу. Вторая половина её ещё лежит в кэше, а первая уже выдавлена оттуда данными другой таблицы, нужными для выполнения запроса. Конечно, наиболее оптимальным будет начать передачу данных клиенту с этих записей, а пока они передаются, подчитать остальные, и передать их позже. Вот тебе порядок-то и поломался...

===

PS. Кстати, правило выбора индекса, который будет использоваться в качестве кластерного, имеет неприятный побочный эффект. Если у некоторых полей, входящих в какие-то индексы, изменяется свойство NULLability, то это может привести к изменению того, какой из имеющихся индексов станет использоваться в качестве первичного по пункту 2. В результате мы получим невозможность использования INSTANT / INPLACE методов, и будет использован длинный COPY. Впрочем, ситуация такая крайне редка.

• Выделение отдельного помещения для размещения внешнего ввода (Интернет и телефонные линии), кросса, серверов и активного оборудования. Металлическая дверь, кодовый замок.
  
• Три линии питания - две для питания оборудования, причём запитанные от разных лучей, или хотя бы от разных фаз, плюс одна для питания кондиционера (минимум 7 кВт), плюс дежурное освещение.
  
• Система пожаротушения - газовая, углекислота или фреон. Порошок - нафиг, случись что, всё оборудование можно выбрасывать и закупать новое. Воды быть не должно в принципе - даже просто проходящих через помещение труб.
  
• Обязательно стойка (или стойки). Лотки, органайзеры, включая органайзеры электропитания.
  
• Обязательно бесперебойники - причём время удержания должно быть минимум часа полтора, причём с учётом рабочей деградации батарей.
  
• СКС разводится от розеток возле рабочих мест и до патч-панелей стойки витой парой 5 или 5е категории, чистой одножильной медью, многожилка или омеднённый алюминий ни в коем случае. Какие-то промежуточные и местные коммутаторы - забудь как страшный сон. Прокладка - по запотолочным металлическим лоткам, последний метр в коробе, монтаж на встраиваемые в короб розетки (для рабочих мест в центре комнаты - напольные короба и встраиваемые в пол розеточные блоки). Прокладка до внешних камер соответственно проводом для внешней прокладки, розетки во влагозащищённых распаечных коробках (по опыту - минимум 100х150). С розетками внутри не жадничать - на одно рабочее место минимум 2 розетки (локальная сеть, телефон), плюс дополнительные для сетевых принтеров и для точек доступа, ну и учесть, что сотрудники любят переставлять мебель самым идиотским образом. Судя по чертежам и описанию - будет штук 200 розеток.
  
• Коммутаторы - управляемые как минимум L2+, PoE для подключения точек доступа, видеокамер и IP-телефонов, обычные для подключения компов и сетевых принтеров. Модель не сильно важна, но лучше сразу иметь дохрена резервных портов, чем потом докупать. Клиентские порты гигабит однозначно. Но я бы рекомендовал брать с хотя бы парой 10-гигабитных портов. Вендор по вкусу (лично я бы ставил D-Link).
  
• Маршрутизатор - согласен с предыдущими товарищами насчёт Микротика вменяемой старшей модели.
  
• Точки доступа - лучше сразу брать комплект для бесшовного покрытия всего здания. Насчёт количества, размещения и необходимости внешних антенн вместо встроенных ничего не скажу - это только по месту решается.
  

Ну по минимуму где-то так.

Запись пакетом быстрее и менее нагрузочна, но выше вероятность потери при сбоях.

PS. 40 записей в секунду - это в общем-то ни о чём..