Въпрос относно MySQL индексите
Голяма таблица (милиони записи). Редовете са задачи за обработка. Когато се добави запис, флагът „обработен“ се задава на 0. След това отделна услуга обработва записите и променя флага на 1. Записите не се изтриват, флагът никога не преминава от състояние 1 в състояние 0. В полето на флага се задава индекс. Изисква се да запомните времето, когато е обработен файлът (unix_timestamp в int).
Въпросът е възможно ли е да се премахне флага от таблицата и да се направи селекция само по време на обработка (processed_time = 0)? Или индекс на поле с флаг 0/1 ще работи по-ефективно, отколкото на int поле?
Трудно е да се каже недвусмислено, има различни взаимно компенсиращи се ефекти. От една страна, можете да се отървете от полето с флага, който вече не е необходим - това е плюс, от друга страна, ще трябва да добавите индекс към полето с клеймо за време, което вече заема повече от един байт, като предишното - това е минус (индексът ще заема много памет). Самите индекси ще работят еднакво ефективно за определената селекция.
Ако бях на ваше място, щях да създам тестова табела и да направя бенчмарк, в същото време, въз основа на резултатите, можете да отпишете статия в Habr, много биха се заинтересували.
Въпросът за избора на машина за съхранение също не е тривиален, innodb ще има много забележими допълнителни разходи за заглавки на редове, ако структурата на таблицата е много проста и размерът на реда е малък.
Трябва да се тества...
Същото важи и за полето processed_time.
Уникалното поле в SQL се отнася до полета без дублиращи се стойности. При вас стойност 0, както разбирам, се повтаря.
| предупреждавам | БРОЯ(*) |
| -1 | 3792 |
| 0 | 529637 |
| 137888 | 3 |
Във втория случай е използван индекс.
саморазходвантестване. Оказах се, че греша.
Има мнения, с които не съм съвсем съгласен. Нека да разгледаме какво е индекс в опростена форма.
Ако индексът на полето не е зададен, тогава той преминава през всички записи и сравнява, ако флагът = 1, тогава изберете записа. С един милион записа ще има милион такива сравнения.
Ако поставите индекс, това ще намали списъка до уникални стойности и ще изглежда така: 0 - редове, където записът е 0 1 - редове, където записът е 1
Тоест ще има само 2 сравнения.
Ако комбинирате полетата, тогава индексът ще има 999 900 уникални временни стойности и една - 0, съответстваща на 100 записа, тоест ще има 999 901 сравнения.
(ако полето изобщо е уникално, тогава предимството е, че ще спре търсенето след първия намерен елемент)
(това не е всичко, в което работят индексите, освен това има различни видове, нюанси)
Колко значимо е сравнението на цели числа, дори умножени по милион, не се наемам да съдя, както и за увеличаването на достъпа до твърдия диск. Но определено ще бъде по-дълго, единственият въпрос е колко, тук вече е необходимо да се тества.
Друга ситуация с NULL. IS NULL - винаги ще работи без сравнение. Това е мястото, където бих го направил.