При попытке выполнить этот запрос мой процессор mysql cpu использует 100%, а страница просто кивает. Я устанавливаю индекс на (Client_Code, Date_Time, Time_Stamp, Activity_Code, Employee_Name, ID_Transaction), он, похоже, не помогает. Какие шаги я могу предпринять, чтобы исправить эту проблему? Также в базе данных уже есть один индекс, если это имеет значение. благодаря
Вот что делает этот запрос
Информация о базе данных
ID_Transaction | Client_Code | Employee_Name | Date_Time |Time_Stamp| Activity_Code 1 | 00001 | Eric | 11/15/10| 7:30AM | 00023 2 | 00001 | Jerry | 11/15/10| 8:30AM | 00033 3 | 00002 | Amy | 11/15/10| 9:45AM | 00034 4 | 00003 | Jim | 11/15/10| 10:30AM | 00063 5 | 00003 | Ryan | 11/15/10 | 12:00PM | 00063 6 | 00003 | bill | 11/14/10 | 1:00pm | 00054 7 | 00004 | Jim | 11/15/10 | 1:00pm | 00045 8 | 00005 | Jim | 11/15/10| 10:00 AM| 00045 Запрос берет информацию выше и подсчитывает ее так. По последней записи для каждого client_code. В этом случае запрос будет выглядеть так. После php.
Jerry = 1 2 | 00001 | Jerry | 11/15/10| 8:30AM | 00033 Amy = 1 3 | 00002 | Amy | 11/15/10| 9:45AM | 00034 Ryan = 1 5 | 00003 | Ryan | 11/15/10 | 12:00PM | 00063 Jim = 2 7 | 00004 | Jim | 11/15/10 | 1:00pm | 00045 8 | 00005 | Jim | 11/15/10| 10:00 AM| 00045 $sql = "SELECT m.Employee_Name, count(m.ID_Transaction) FROM ( SELECT DISTINCT Client_Code FROM Transaction) md JOIN Transaction m ON m.ID_Transaction = ( SELECT ID_Transaction FROM Transaction mi WHERE mi.Client_Code = md.Client_Code AND Date_Time=CURdate() AND Time_Stamp!='' AND Activity_Code!='000001' ORDER BY m.Employee_Name DESC, mi.Client_Code DESC, mi.Date_Time DESC, mi.ID_Transaction DESC LIMIT 1 ) group by m.Employee_Name";
Есть ли лучший способ написать этот запрос, чтобы он не повредил мою систему? Запрос отлично работает с 10 записями базы данных, но он блокирует мой сервер, когда база данных содержит 300 000 записей.
Спасибо Эрику
+----+--------------------+-------------+--------+------------------------+--------------+---------+----------------+------+----------+----------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+--------------------+-------------+--------+------------------------+--------------+---------+----------------+------+----------+----------------------------------------------+ | 1 | PRIMARY | <derived2> | ALL | [NULL] | [NULL] | [NULL] | [NULL] | 8 | 100.00 | Using temporary; Using filesort | | 1 | PRIMARY | m | index | [NULL] | search index | 924 | [NULL] | 21 | 100.00 | Using where; Using index; Using join buffer | | 3 | DEPENDENT SUBQUERY | mi | ref | search index,secondary | search index | 18 | md.Client_Code | 3 | 100.00 | Using where; Using temporary; Using filesort | | 2 | DERIVED | Transaction | index | [NULL] | secondary | 918 | [NULL] | 21 | 38.10 | Using index | +----+--------------------+-------------+--------+------------------------+--------------+---------+----------------+------+----------+----------------------------------------------+
Как насчет перехода с несколькими GROUP BY вместо всех подзапросов, чтобы упростить вещи … что-то вроде:
SELECT * FROM Transaction WHERE Date_Time=CURdate() AND Time_Stamp!='' AND Activity_Code != '000001' GROUP BY Client_Code, Employee_Name
Если я правильно понимаю ваш запрос, то что-то подобное разрешит проблемы и предотвратит необходимость в подзапросах.
Вы обязательно захотите сделать соединение вместо подбора select.
Кроме того, сколько записей вы просматриваете? Является ли разбиение на страницы и использование лимита из вопроса?
Если вы настроите свой первоначальный запрос, измененный с помощью внутренних / внешних соединений, как вид, и он не сработает, вы будете на один шаг ближе. Как только представление будет настроено, вы сможете использовать гораздо менее сложный оператор select – потенциально разбитый на страницы.