След пускане на една определена заявка MySQL-а ми забива.

Версия 3.23.53.

Заявката е следната:

SELECT
COUNT(*) length
FROM
VISITOR v LEFT JOIN SEARCH_STAT s
ON
v.visitor_sid=s.visitor_sid
WHERE
DATE_FORMAT(s.datetime, '%Y-%m-%d')!=CURDATE()
GROUP BY
v.visitor_sid

Таблиците:

mysql> desc visitor;
+-------------+---------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+---------------------+------+-----+---------+----------------+
| VISITOR_SID | bigint(20) unsigned | | PRI | NULL | auto_increment |
| DATETIME | datetime | YES | | NULL | |
+-------------+---------------------+------+-----+---------+----------------+
2 rows in set (0.01 sec)

mysql> desc search_stat;
+-----------------+---------------------+------+-----+---------+----------------
+
| Field | Type | Null | Key | Default | Extra
|
+-----------------+---------------------+------+-----+---------+----------------
+
| SEARCH_STAT_SID | bigint(20) unsigned | | PRI | NULL | auto_increment
|
| VISITOR_SID | bigint(20) unsigned | | | 0 |
|
| DATETIME | datetime | YES | | NULL |
|
| IP | int(10) unsigned | | | 0 |
|
| KEYWORD | varchar(255) | YES | | NULL |
|
+-----------------+---------------------+------+-----+---------+----------------
+
5 rows in set (0.00 sec)

Explain select на същата заявка дава следното:


+-------+-------+---------------+---------+---------+------+--------+-----------
-------------------+
| table | type | possible_keys | key | key_len | ref | rows | Extra
|
+-------+-------+---------------+---------+---------+------+--------+-----------
-------------------+
| v | index | NULL | PRIMARY | 8 | NULL | 1940 | Using inde
x; Using temporary |
| s | ALL | NULL | NULL | NULL | NULL | 112347 | where used
|
+-------+-------+---------------+---------+---------+------+--------+-----------
-------------------+
2 rows in set (0.00 sec)


И така има ли нещо нередно, освен тези 112347 реда?!

Съдържаниет е скрито
Влезте за да го видите

niama6 tarpenie da ia iz4aka6 da zavar6i mai ....
zajavkata ti e bavna i moze da te4e obrabotkata i 1-2-3 chasa zavisi ot ma6inata
na tvoe miasto ne bih polzval LEFT JOIN a taka :
SELECT ..... FROM VISITOR v ,SEARCH_STAT s WHERE v.visitor_sid=s.visitor_sid
AND DATE_FORMAT(s.datetime, '%Y-%m-%d')!=CURDATE()
GROUP BY
v.visitor_sid
traibva da e pone 10 pati po-barzo

E tuk ni6to niama :

Съдържаниет е скрито
Влезте за да го видите

А защо реши, че забива?


WHERE DATE_FORMAT(s.datetime, '%Y-%m-%d')!=CURDATE()

това кактоси го написал винаги ще преравя всички редове от таблицата независимо дали има индекс или не - причините са точно 2. Едната можеш да я избегнеш (функция върху колонка от таблицата), но другата не можеш: !=

!= е изключително гадно нещо за базите данни и ако искаш да го оптимизираш трябва (естествено след като добавиш индекс по тази колонка) да използваш

select ...
where d < cudate()
union
select ...
where d > curdate()


Само, че в случаю ти си направо за бой поради что-то таблицити ти се казват visitor и search_stat се хващам на бас на 2 каси бира, че нямаш НИТО ЕДИН РЕД дата > днес! И няма и да имаш.

така ли е?

Ако е така МАРШ да добавяш индекс:

ALTER TABLE search_stat ADD KEY(datetime);

.... WHERE `datetime` < CURDATE();

ще ти даде същото - така ли е?

Хващам се на бас, че EXPLAIN ше покаже по-различна история.

Друг е въпроса, че това сигурно няма да ти помогне ако пазиш данни за много време назад.


Задължително обаче - на всяка цена добави в search_stat индекс KEY(visitor_sid)

Колонките по които правиш JOIN трабва да са индексирани - в 99.99% от случаите това ускорява многократно работата.

Нередното в резултата от EXPLAIN не е числото 112347 а всичко останало


Особено първата колонка - ALL

Съдържаниет е скрито
Влезте за да го видите

Да, но на мен ми трябва точно LEFT JOIN.

Съдържаниет е скрито
Влезте за да го видите

Наистина машината забива...кликвам някъде и след 2 минути се случва action.

А след съветите, май не остава друго освен да почерпя...2 каси бира не са ли малко множко?

Би трябвало != да е по-добре от <, > или в най-лошия случай едно и също?

Съдържаниет е скрито
Влезте за да го видите

не е същото
ако има индекси е по зле....

Съдържаниет е скрито
Влезте за да го видите

Интересно...това пише ли го някъде из docs?

Съдържаниет е скрито
Влезте за да го видите

да
в главата за индексите...

Съдържаниет е скрито
Влезте за да го видите

Няма нужда да го пише.

Представи си, че вършиш всичко на ръка и ще разбереш защо е прав Торбалан.

Имаш Книга - таблица. Всяка Страница e като Ред.
Индекс - точно същото като Индекса на края на книгата

Отваряш значи там и търсиш на коя страница се среща думата Чушка

Прелистваш индекса и търсиш Ч...Ч .... Чу...Чушка!!! И там пише - страници 10, 24,434,523

.... WHERE ... = 'чушка'


Ха сега си представи какво му е на сървъра като трябва намери Всички страници дето НЕ се среща Чушката.
... WHERE ... != 'чушка'

Схващаш ли?

А ето и защо Торбалан казва, че < или > са много по-добре от !=

Как ще намериш Всички страници дето се срещат думи > "чушка" в стрингов контекст?

Ми много просто - отваряш на Индекса ама забучваш пръст направо на буква Ч и тръгваш да търсиш Оттам нататък....

Е не е ли по-лесно?

Съдържаниет е скрито
Влезте за да го видите

Мда...изглежда логично...просто разсъждавах без да си давам сметка за индексирането.

Съдържаниет е скрито
Влезте за да го видите