Я маю на увазі наступне:
Якщо створення індексу на таблиці з nрядками вимагає tчасу. Створення індексу в одній таблиці 1000*nзабирає приблизно 1000*tчас.
Я намагаюся досягти - це оцінити час, необхідний для створення індексу на виробничій базі даних, створивши той самий індекс на значно меншій тестовій базі даних.
Відповіді:
Створення індексу по суті є своєрідною операцією , тому в кращому випадку має складність зростання порядку n log nв середньому (ви можете виявити, що це робить краще в деяких випадках, і, швидше за все, не буде набагато гірше).
Якщо всі ваші відповідні сторінки даних вписуються в оперативну пам’ять і вже є в оперативній пам’яті, і індекс також підходить, а ваші СУБД не змушують записувати сторінки індексів до завершення створення (тому блоки індексів не оновлюються на диску кілька разів протягом операція), тоді швидкість запису результуючого індексу на диск буде більш значною, ніж час, необхідний для виконання сортування - тому ви можете виявити, що ви наближаєтесь до лінійної залежності між кількістю рядків та часом створення індексу - але якщо ви припускаєте гірший випадок, ви рідше неприємно здивовані!
Пам’ятайте, що якщо ви не збираєтеся зупиняти доступ до виробничої бази даних під час операції, будь-який створений індекс буде конкурувати за пропускну здатність IO та / або блокування з іншою діяльністю, тому вам слід спробувати врахувати це, якщо ви робите свої тестові оцінки часу. в іншій системі, навіть якщо вона однаково налаштована.
Також варто відзначити, що якщо ви зможете розділити шпинделі для індексів від шпинделів для таблиці, ви зможете працювати з двох дисків одночасно (все ще обмежуєтесь швидкістю дискового контролера посередині, якщо RAID або подібне, але все одно це буде швидше, ніж один диск).
Я усвідомлюю, що створення індексу не є повністю операцією читання-запису, але вона значно прискорює роботу.
CAVEATS: Я сам MSSQL хлопець, і тому я не впевнений у MySQL, але я повинен уявити, що концепція розщеплення шпинделів не є специфічною для SQLServer та Oracle (де я чув, що про це говорили і там, IIRC ). Я просто не знаю, як рухатись до створення цієї концепції. Але в термінах SQLServer це означатиме, що крім цього є окрема файлова група PRIMARYта розміщення індексів на іншій групі файлів, при цьому інша файлова група призначена для набору шпинделів, які не включають PRIMARY(надане розміщення шпинделя проти файлових груп - це зовсім інша історія)
Це залежить.
Змінна №1: Якщо MySQL вирішить будувати індекси на ходу, або чекати, поки всі дані знайдуться, то зробіть сортування тощо, щоб створити індекс. Примітка: індекси UNIQUE (я думаю) повинні бути побудовані на льоту, щоб можна було перевірити унікальність. ПЕРШИЙ КЛЮЧ для InnoDB зберігається з даними (або ви можете вказати їх навпаки), так що ОБОВ'ЯЗКОВО будувати випадковим чином.
Змінна №2: Індекс відстежує дані (наприклад, AUTO_INCREMENT або часові позначки) проти випадкових (GUID, MD5) або десь посередині (номер деталі, ім'я, friend_id).
Змінна №3 (якщо індекс побудований на льоту): індекс може вміститися в кеші (key_buffer або innodb_buffer_pool), або він може перекинутися на диск.
Індекси, які відстежують дані, є ефективними та практично лінійними, незалежно від відповіді на номер 1.
Випадкові ІД - це біль. Якщо індекс не впишеться в кеш, час його побудови буде набагато гіршим, ніж лінійний, незалежно від інших змінних. (Я не погоджуюся з Rolando в цьому випадку.) Величезна таблиця InnoDB з GUID для PK болісно повільно ВСТАВИТИ - плануйте зі 100 рядків / сек для звичайних дисків; можливо, 1000, якщо у вас є SSD. ЗАВАНТАЖЕННЯ ДАНИХ та пакетних ВСТУП не перешкоджає повільності випадкового зберігання.
3,53 через 5,6 - мало що змінилося.
Кілька шпинделів? RAID-зйомка краще майже в будь-якій ситуації, ніж призначати її вручну тут і тому. Ручне розщеплення призводить до незбалансованих ситуацій - сканування таблиці застрягло на диску даних; на індексному диску застрягла лише операція з індексом; запит самотнього спочатку потрапляє на індексний диск, потім диск даних (без перекриття); тощо.