I'm stuck with the following problem and hope, that someone help me to solve it...
Mysql version 5.6.19-0ubuntu0.14.04.1-log.
CREATE TABLE `dr` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`start_date` bigint(20) unsigned NOT NULL,
`end_date` bigint(20) unsigned NOT NULL,
UNIQUE KEY `id` (`id`,`start_date`),
KEY `start_date` (`start_date`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED;
CREATE TABLE `map_dr2pdu` (
`drtable_id` int(10) unsigned NOT NULL,
`dr_id` bigint(20) unsigned NOT NULL,
`packet_location` bigint(20) unsigned NOT NULL,
`sctp_chunk` smallint(5) unsigned DEFAULT NULL,
KEY `dr_id` (`dr_id`),
KEY `drtable_id` (`drtable_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED;
CREATE TABLE `dr_hot` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`start_date` bigint(20) unsigned NOT NULL,
`end_date` bigint(20) unsigned NOT NULL,
UNIQUE KEY `id` (`id`,`start_date`)
) ENGINE=MEMORY;
CREATE TABLE `map_dr2pdu_hot` (
`drtable_id` int(10) unsigned NOT NULL,
`dr_id` bigint(20) unsigned NOT NULL,
`packet_location` bigint(20) unsigned NOT NULL,
`sctp_chunk` smallint(5) unsigned DEFAULT NULL,
KEY `dr_id` (`dr_id`),
KEY `drtable_id` (`drtable_id`)
) ENGINE=MEMORY;
dr and map_dr2pdu have partitions (if it matters).
dr_hot.id <===> map_dr2pdu_hot.dr_id
There is a client C1 (auto commit off)
writes into dr_hot
obtains LAST_INSERTED_ID and inserts 1-n records into map_dr2pdu_hot.
C1 commit politics: 500 inserts or 1 sec (which came first)
Memory tables are introduced solely to support high insertion rate. Actual data must be store in dr and map_dr2pdu (INNODB) tables. To make this "rotation"
there is second client C2 (auto commit off) which
locks _hot table,
stores its autoincrement id
dumps its data into file in memory,
truncates _hot table (faster, than delete)
updates its autoincrement id
commit
unlocks the table
[loads data from the file to INNODB table]
Problem appears when C2 begins its work:
mysql> show processlist;
+--------+-----------------+-----------------+-----------+---------+-------+----------------+---------------+----+
| Id | User | Host | db | Command | Time | State | Info |
+--------+-----------------+-----------------+-----------+---------+-------+---------------------------------+----+
| 1 | event_scheduler | localhost | NULL | Daemon | 1 | Waiting for next activation | NULL |
| 57 | riva | localhost | riva | Sleep | 283 | | NULL |
| 115748 | root | localhost | riva | Query | 0 | init | show processlist |
| 117538 | riva | localhost | riva | Sleep | 10889 | | NULL |
| 120150 | riva | localhost | riva | Sleep | 30 | | NULL |
| 120155 | riva | localhost | riva | Sleep | 7 | | NULL |
| 120158 | riva | localhost | riva | Sleep | 5 | | NULL |
| 120161 | riva | localhost | riva | Sleep | 5 | | NULL |
| 120164 | riva | localhost | riva | Sleep | 5 | | NULL |
| 120167 | riva | localhost | riva | Sleep | 7 | | NULL |
| 120170 | riva | localhost | riva | Query | 22 | Waiting for table metadata lock | ALTER TABLE dr_hot AUTO_INCREMENT=1152885790 |
| 120178 | riva | localhost | riva | Sleep | 5 | | NULL |
| 120179 | riva | localhost | riva | Query | 23 | Waiting for table metadata lock | LOCK TABLES map_dr2pdu_hot LOW_PRIORITY WRITE |
| 120243 | riva | localhost | riva | Sleep | 24 | | NULL |
| 120244 | riva | localhost:40934 | riva | Sleep | 24 | | NULL |
| 120245 | riva | localhost:40935 | riva | Sleep | 24 | | NULL |
| 120246 | riva | localhost:40936 | riva | Sleep | 22 | | NULL |
| 120247 | riva | localhost:40937 | riva | Sleep | 24 | | NULL |
| 120248 | riva | localhost:40938 | riva | Sleep | 24 | | NULL |
| 120249 | riva | localhost:40939 | riva | Sleep | 24 | | NULL |
| 120250 | riva | localhost:40940 | riva | Sleep | 24 | | NULL |
| 120251 | riva | localhost:40941 | riva | Sleep | 22 | | NULL |
| 120252 | riva | localhost:40942 | riva | Sleep | 22 | | NULL |
| 120253 | riva | localhost:40943 | riva | Execute | 22 | Waiting for table metadata lock | INSERT INTO map_dr2pdu_hot (xdrtable_id, xdr_id, packet_location) VALUES (25, 6078, |
+--------+-----------------+-----------------+-----------+---------+-------+---------------------------------+------+
24 rows in set (0.00 sec)
mysql general_log + processlist:
119177 Execute INSERT INTO map_dr2pdu_hot (drtable_id, dr_id, packet_location) VALUES (26, 131287232, 606
4773029186237937)
119177 Query COMMIT
119453 Query LOCK TABLES map_dr2pdu_hot WRITE
processlist:
| 119453 | rivasense | localhost | rivasense | Query | 164 | Waiting for table metadata lock | LOCK TABLES map_dr2pdu_hot WRITE
119177 Query START TRANSACTION
119177 Execute INSERT INTO dr_hot ()
Show engine innodb status, does not show any deadlock, just like
mysql> select * from INNODB_LOCKS;
Empty set (0.04 sec)
mysql> select * from INNODB_LOCK_WAITS;
Empty set (0.00 sec)
As I understoo : C1 acquires lock for insert and seems not commits, but it DOES according to log. therefore, C2 can't lock table.
Please help to find the root cause.
update on 06/10/14:
Basically problem reproducible when C1 tries to write something into map_dr2pdu_hot and C2 simultaneously tries to lock the same table. This treated as "almost" deadlock (not listed among deadlocks) and released with lock_wait_timeout expired.
Could you suggest how to resolve such a problem?
Finally we had to apply WA - modify algorithm of C2 to:
stores _hot tbl autoincrement id
dumps its data into file in memory,
deletes from _hot table (where id less than auto inc id from step 1)
loads data from the file to INNODB table
of course map_dr2pdu table altered to have id auto-increment column.
Related
i have a performance problem in MySQL.
I have a table with 215000 rows (InnoDB Engine) inserted in it and to execute the function SUM() on one column for only 1254 rows is taking 500ms.
The version i am using is : MySQL 5.7.32
The computer specs are the following:
Core I5 3.0 Ghz
8 Gb Ram
Solid State Drive
Here i leave information about the structure of the database:
mysql> select count(*) from cuenta_corriente;
+----------+
| count(*) |
+----------+
| 214514 |
+----------+
mysql> describe cuenta_corriente;
+-----------------------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+-------------+------+-----+---------+----------------+
| ID_CUENTA_CORRIENTE | int(11) | NO | PRI | NULL | auto_increment |
| ID_CLIENTE | int(11) | YES | MUL | NULL | |
| ID_PROVEEDOR | int(11) | YES | MUL | NULL | |
| FECHA | varchar(50) | YES | MUL | NULL | |
| FECHA_FISCAL | varchar(50) | YES | | NULL | |
| ID_OPERACION | int(11) | YES | MUL | NULL | |
| ID_TIPO_OPERACION | int(11) | YES | MUL | NULL | |
| DEBE | double | YES | | 0 | |
| HABER | double | YES | | 0 | |
| TOTAL | double | YES | | 0 | |
| SALDO_ANTERIOR | double | YES | | 0 | |
| SALDO_ACTUAL | double | YES | | 0 | |
| ID_OPERACION_ASOCIADA | int(11) | YES | | NULL | |
| ELIMINADO | int(11) | YES | | 0 | |
| ID_EMPLEADO | int(11) | NO | | 0 | |
+-----------------------+-------------+------+-----+---------+----------------+
show indexes from cuenta_corriente;
+------------+------------------------------------------------------------+
| Non_unique | Key_name Column_name |
+------------+------------------------------------------------------------+
| 0 | PRIMARY ID_CUENTA_CORRIENTE |
| 1 | IDX_CUENTA_CORRIENTE ID_CLIENTE |
| 1 | IX_cuenta_corriente_FECHA FECHA |
| 1 | IX_cuenta_corriente_ID_CLIENTE ID_CLIENTE |
| 1 | IX_cuenta_corriente_ID_PROVEEDOR ID_PROVEEDOR |
| 1 | IX_cuenta_corriente_ID_TIPO_OPERACION ID_TIPO_OPERACION |
| 1 | IX_cuenta_corriente_ID_OPERACION ID_OPERACION |
| 1 | IDX_cuenta_corriente_ID_OPERACION ID_OPERACION |
+------------+------------------------------------------------------------+
8 rows in set (0.00 sec)
The problem is with the folowing queries, in my opinion they are taking too long, considering that i have an index for the column ID_CLIENTE and that there are only 1254 rows with the ID_CLIENTE column = 19. Here are the query results:
mysql> SELECT COUNT(*) FROM CUENTA_CORRIENTE WHERE ID_CLIENTE = 19;
1254 rows
mysql> SELECT DEBE FROM CUENTA_CORRIENTE WHERE ID_CLIENTE = 19;
1254 rows - 0.513 sec
mysql> SELECT SUM(DEBE) FROM CUENTA_CORRIENTE WHERE ID_CLIENTE = 19;
0.582 sec
The strange thing is if i select all the columns instead selecting only the "DEBE" column, it takes less time:
mysql> SELECT * FROM CUENTA_CORRIENTE WHERE ID_CLIENTE = 19;
0.095 sec
Can anyone help me to improve the performance?
You can make just that query fast by creating a composite index to support it.
ie:
CREATE INDEX IDX_QUERY_FAST ON cuenta_corriente (ID_CLIENTE, DEBE)
But don't forget, each index has to be maintained, so it slows down any inserts into the table, so you don't want 200 indexes supporting every possible query.
With the existing index, the engine should be smart enough to identify the 1200 rows you care about using the index, but then it has to go read all the table records (across however many pages) that have the individual rows to get the DEBE column.
Add this index to help most of the queries you have shown:
INDEX(ID_CLIENTE, DEBE)
and drop INDEX(ID_CLIENTE) if you have such.
Are all of your secondary indexes starting with the PRIMARY KEY?? (The names imply such; please provide SHOW CREATE TABLE to definitively say what columns are in each index.) Don't start an index with the PK; it is likely to be useless.
Run EXPLAIN SELECT ... to see which index a query uses.
When timing a query, run it twice. The first run may spend extra time loading index or data rows into cache (in RAM in the buffer_pool); the second run may be significantly faster because of the caching.
I did a MySQL performance optimization test, but the test results surprised me.
First of all, I prepared several tables for my test, which are "t_worker_attendance_300w(3 million data), t_worker_attendance_1000w(10 million data), t_worker_attendance_1y(100 million data), t_worker_attendance_4y(400 million data)".
Each table has the same field, the same index, they are copied, including 400 million data volume is also increased from 3 million data.
In my understanding, MySQL's performance is bound to be severely affected by the size of the data volume, but the results have puzzled me for a whole week. I've almost tested the scenarios I can think of, but their execution times are the same!
This is a new MySQL 5.6.16 server,I tested any scenario I could think of, including INNER JOIN....
A) SHOW CREATE TABLE t_worker_attendance_4y
CREATE TABLE `t_worker_attendance_4y` (
`id` bigint(20) NOT NULL ,
`attendance_id` char(32) NOT NULL,
`worker_id` char(32) NOT NULL,
`subcontractor_id` char(32) NOT NULL ,
`project_id` char(32) NOT NULL ,
`sign_date` date NOT NULL ,
`sign_type` char(2) NOT NULL ,
`latitude` double DEFAULT NULL,
`longitude` double DEFAULT NULL ,
`sign_wages` decimal(16,2) DEFAULT NULL ,
`confirm_wages` decimal(16,2) DEFAULT NULL ,
`work_content` varchar(60) DEFAULT NULL ,
`team_leader_id` char(32) DEFAULT NULL,
`sign_state` char(2) NOT NULL ,
`confirm_date` date DEFAULT NULL ,
`sign_mode` char(2) DEFAULT NULL ,
`checkin_time` datetime DEFAULT NULL ,
`checkout_time` datetime DEFAULT NULL ,
`sign_hours` decimal(6,1) DEFAULT NULL ,
`overtime` decimal(6,1) DEFAULT NULL ,
`confirm_hours` decimal(6,1) DEFAULT NULL ,
`signimg` varchar(200) DEFAULT NULL ,
`signoutimg` varchar(200) DEFAULT NULL ,
`photocheck` char(2) DEFAULT NULL ,
`machine_type` varchar(2) DEFAULT '1' ,
`project_coordinate` text ,
`floor_num` varchar(200) DEFAULT NULL ,
`device_serial_no` varchar(32) DEFAULT NULL ,
KEY `checkin_time` (`checkin_time`),
KEY `worker_id` (`worker_id`),
KEY `project_id` (`project_id`),
KEY `subcontractor_id` (`subcontractor_id`),
KEY `sign_date` (`sign_date`),
KEY `project_id_2` (`project_id`,`sign_date`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
B) SHOW INDEX FROM t_worker_attendance_4y
+------------------------+------------+------------------+--------------+------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+------------------------+------------+------------------+--------------+------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| t_worker_attendance_4y | 1 | checkin_time | 1 | checkin_time | A | 5017494 | NULL | NULL | YES | BTREE | | |
| t_worker_attendance_4y | 1 | worker_id | 1 | worker_id | A | 1686552 | NULL | NULL | | BTREE | | |
| t_worker_attendance_4y | 1 | project_id | 1 | project_id | A | 102450 | NULL | NULL | | BTREE | | |
| t_worker_attendance_4y | 1 | subcontractor_id | 1 | subcontractor_id | A | 380473 | NULL | NULL | | BTREE | | |
| t_worker_attendance_4y | 1 | sign_date | 1 | sign_date | A | 512643 | NULL | NULL | | BTREE | | |
| t_worker_attendance_4y | 1 | project_id_2 | 1 | project_id | A | 102059 | NULL | NULL | | BTREE | | |
| t_worker_attendance_4y | 1 | project_id_2 | 2 | sign_date | A | 1776104 | NULL | NULL | | BTREE | | |
+------------------------+------------+------------------+--------------+------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
C) EXPLAIN SELECT SQL_NO_CACHE tw.project_id, tw.sign_date FROM t_worker_attendance_4y tw WHERE tw.project_id = '39235664ba734887b298ee568fbb66fb' AND sign_date >= '07/01/2018' AND sign_date < '08/01/2018' ;
+----+-------------+-------+------+-----------------------------------+--------------+---------+-------+----------+--------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+-----------------------------------+--------------+---------+-------+----------+--------------------------+
| 1 | SIMPLE | tw | ref | project_id,sign_date,project_id_2 | project_id_2 | 96 | const | 54134596 | Using where; Using index |
+----+-------------+-------+------+-----------------------------------+--------------+---------+-------+----------+--------------------------+
They all went through the same joint index.
SELECT tw.project_id, tw.sign_date FROM t_worker_attendance_300w tw
WHERE tw.project_id = '39235664ba734887b298ee568fbb66fb'
AND sgin_date >= '07/01/2018'
AND sgin_date < '08/01/2018' LIMIT 0,10000;
Execution time: 0.02 sec
SELECT tw.project_id, tw.sign_date FROM t_worker_attendance_1000w tw
WHERE tw.project_id = '39235664ba734887b298ee568fbb66fb'
AND sgin_date >= '07/01/2018'
AND sgin_date < '08/01/2018' LIMIT 0,10000;
Execution time: 0.01 sec
SELECT tw.project_id, tw.sign_date FROM t_worker_attendance_1y tw
WHERE tw.project_id = '39235664ba734887b298ee568fbb66fb'
AND sgin_date >= '07/01/2018'
AND sgin_date < '08/01/2018' LIMIT 0,10000;
Execution time: 0.02 sec
SELECT tw.project_id, tw.sign_date FROM t_worker_attendance_4y tw
WHERE tw.project_id = '39235664ba734887b298ee568fbb66fb'
AND sgin_date >= '07/01/2018'
AND sgin_date < '08/01/2018' LIMIT 0,10000;
Execution time: 0.02 sec
......
My guess is that MySQL's query performance will decline dramatically with the increase of data volume, but they are not much different. So I have no way to optimize my query. I don't know when to implement table partition plan or sub-database sub-table plan.
What I want to know is why the execution speed of index with small data volume is the same as that of index with large data volume. If you can help me, I would like to thank you very much.
Same search performance on large data volume because of BTREE index. It has O(log(n)). Relatively speaking that means that search algorithm have to complete:
6 operations on 3m of data
7 operations on 10m of data
8 operations on 100m of data
8 operations on 400m of data
Аs you can see the number of operations is almost the same.
My guess is that MySQL's query performance will decline dramatically with the increase of data volume
This is true for full table scan cases.
I have a new answer, someone told me "Because your query is covered by index, index is actually the time of query index. Mysql index uses B + tree structure. The query time is basically the same under the same tree height. You can calculate whether the height of the trees indexed by these tables is the same."
So I did the inquiry as required.
mysql> SELECT b.name, a.name, index_id, type, a.space, a.PAGE_NO
-> FROM information_schema.INNODB_SYS_INDEXES a,
-> information_schema.INNODB_SYS_TABLES b
-> WHERE a.table_id = b.table_id AND a.space <> 0;
+-------------------------------------------------+---------------------+----------+------+-------+---------+
| name | name | index_id | type | space | PAGE_NO |
+-------------------------------------------------+---------------------+----------+------+-------+---------+
| mysql/innodb_index_stats | PRIMARY | 18 | 3 | 2 | 3 |
| mysql/innodb_table_stats | PRIMARY | 17 | 3 | 1 | 3 |
| mysql/slave_master_info | PRIMARY | 20 | 3 | 4 | 3 |
| mysql/slave_relay_log_info | PRIMARY | 19 | 3 | 3 | 3 |
| mysql/slave_worker_info | PRIMARY | 21 | 3 | 5 | 3 |
| test_gomeet/t_worker_attendance_1y | GEN_CLUST_INDEX | 45 | 1 | 12 | 3 |
| test_gomeet/t_worker_attendance_1y | checkin_time | 46 | 0 | 12 | 16389 |
| test_gomeet/t_worker_attendance_1y | project_id | 50 | 0 | 12 | 32775 |
| test_gomeet/t_worker_attendance_1y | worker_id | 53 | 0 | 12 | 49161 |
| test_gomeet/t_worker_attendance_1y | subcontractor_id | 54 | 0 | 12 | 65547 |
| test_gomeet/t_worker_attendance_1y | sign_date | 66 | 0 | 12 | 81933 |
| test_gomeet/t_worker_attendance_1y | project_id_2 | 408 | 0 | 12 | 98319 |
| test_gomeet/t_worker_attendance_300w | GEN_CLUST_INDEX | 56 | 1 | 13 | 3 |
| test_gomeet/t_worker_attendance_300w | checkin_time | 58 | 0 | 13 | 16389 |
| test_gomeet/t_worker_attendance_300w | project_id | 59 | 0 | 13 | 16427 |
| test_gomeet/t_worker_attendance_300w | worker_id | 60 | 0 | 13 | 16428 |
| test_gomeet/t_worker_attendance_300w | subcontractor_id | 61 | 0 | 13 | 16429 |
| test_gomeet/t_worker_attendance_300w | sign_date | 67 | 0 | 13 | 65570 |
| test_gomeet/t_worker_attendance_300w | project_id_2 | 397 | 0 | 13 | 81929 |
| test_gomeet/t_worker_attendance_4y | GEN_CLUST_INDEX | 42 | 1 | 9 | 3 |
| test_gomeet/t_worker_attendance_4y | checkin_time | 47 | 0 | 9 | 16389 |
| test_gomeet/t_worker_attendance_4y | worker_id | 49 | 0 | 9 | 32775 |
| test_gomeet/t_worker_attendance_4y | project_id | 52 | 0 | 9 | 49161 |
| test_gomeet/t_worker_attendance_4y | subcontractor_id | 55 | 0 | 9 | 65547 |
| test_gomeet/t_worker_attendance_4y | sign_date | 69 | 0 | 9 | 81933 |
| test_gomeet/t_worker_attendance_4y | project_id_2 | 412 | 0 | 9 | 98319 |
+-------------------------------------------------+---------------------+----------+------+-------+---------+
mysql> SHOW GLOBAL STATUS LIKE 'Innodb_page_size';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| Innodb_page_size | 16384 |
+------------------+-------+
root#localhost:/usr/local/mysql/data/test_gomeet# hexdump -s 49216 -n 02 t_worker_attendance_300w.ibd
000c040 0200
000c042
root#localhost:/usr/local/mysql/data/test_gomeet# hexdump -s 49216 -n 02 t_worker_attendance_1y.ibd
000c040 0300
000c042
root#localhost:/usr/local/mysql/data/test_gomeet# hexdump -s 49216 -n 02 t_worker_attendance_4y.ibd
000c040 0300
000c042
The calculation shows that 3.34 is 100 million and 3.589 is 400 million. It's almost the same. Is it because of this?
My Django client was very slow during MySQL queries. Doing a tcpdump on the MySQL server, I saw that the following SQL query
"UPDATE `django_session` SET `session_data` = " [data]
is very long. What is the simplest way to solve this problem ?
Thank you.
------------------------- EDIT 1
the size of [data] is very big and it is taking a very long time to transfer.
------------------------- EDIT 2
mysql> SHOW INDEX FROM django_session;
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+----------------+------------+-------------------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| django_session | 0 | PRIMARY | 1 | session_key | A | 9496 | NULL | NULL | | BTREE | | |
| django_session | 1 | django_session_expire_date_a5c62663 | 1 | expire_date | A | 9496 | NULL | NULL | | BTREE | | |
2 rows in set (0,02 sec)
mysql> SHOW CREATE TABLE django_session;
| Table | Create Table |
+----------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| django_session | CREATE TABLE django_session (
session_key varchar(40) NOT NULL,
session_data longtext NOT NULL,
expire_date datetime NOT NULL,
PRIMARY KEY (session_key),
KEY django_session_expire_date_a5c62663 (expire_date)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
1 row in set (0,01 sec)
My Magento(Vesion 1.8.0.0) website was running without any problem when I was using MySQL5.5 database for years. After moving to mariadb-server-10.2 recently(exported data using sqldump and then imported on new mariadb server), many times PHP child process stays in waiting states until max_execution_time expires and finally php-fpm stops responding.
On investigation I found that all the php child processes are waiting on database queries. I checked the processlist on mariadb when I encountered the problem recently and output is below. Any idea how I could fix this? Thanks in advance.
MariaDB [(none)]> show processlist;
+--------+-------------+-------------------------------+---------+---------+------+------------------------------+---------------------------------------------------------------------- --------------------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+--------+-------------+-------------------------------+---------+---------+------+------------------------------+---------------------------------------------------------------------- --------------------------------+----------+
| 1 | system user | | NULL | Daemon | NULL | | NULL | 0.000 |
| 2 | system user | | NULL | Daemon | NULL | | NULL | 0.000 |
| 4 | system user | | NULL | Daemon | NULL | | NULL | 0.000 |
| 3 | system user | | NULL | Daemon | NULL | | NULL | 0.000 |
| 5 | system user | | NULL | Daemon | NULL | InnoDB shutdown handler | NULL | 0.000 |
| 109822 | catalog | mymagentositexxxxxx.com:56405 | catalog | Query | 985 | update | INSERT INTO `cataloginventory_stock_status` (`product_id`,`website_id `,`stock_id`,`qty`,`stock_statu | 0.000 |
| 109850 | catalog | mymagentositexxxxxx.com:56436 | catalog | Query | 985 | update | INSERT INTO `cataloginventory_stock_status` (`product_id`,`website_id `,`stock_id`,`qty`,`stock_statu | 0.000 |
| 109859 | catalog | mymagentositexxxxxx.com:56448 | catalog | Query | 985 | update | INSERT INTO `cataloginventory_stock_status` (`product_id`,`website_id `,`stock_id`,`qty`,`stock_statu | 0.000 |
| 109931 | catalog | mymagentositexxxxxx.com:56554 | catalog | Query | 986 | Waiting for table level lock | DELETE FROM `catalogsearch_fulltext` WHERE (store_id=1) AND (product_ id IN ('26515')) | 0.000 |
| 109966 | catalog | mymagentositexxxxxx.com:56606 | catalog | Query | 984 | Waiting for table level lock | INSERT INTO `catalogsearch_result` SELECT 33218 AS `query_id`, `s`.`p roduct_id`, 0 AS `relevance` FR | 0.000 |
| 109993 | catalog | mymagentositexxxxxx.com:56645 | catalog | Query | 934 | update | INSERT INTO `sales_flat_quote_item` (`quote_id`, `created_at`, `updat ed_at`, `product_id`, `store_id | 0.000 |
| 109997 | catalog | mymagentositexxxxxx.com:56650 | catalog | Query | 987 | Sending data | INSERT INTO `catalogsearch_result` SELECT 33215 AS `query_id`, `s`.`p roduct_id`, 0 AS `relevance` FR | 0.000 |
| 110040 | catalog | mymagentositexxxxxx.com:56709 | catalog | Query | 983 | Waiting for table level lock | INSERT INTO `catalogsearch_result` SELECT 33215 AS `query_id`, `s`.`p roduct_id`, 0 AS `relevance` FR | 0.000 |
| 110218 | catalog | mymagentositexxxxxx.com:56925 | catalog | Query | 940 | Waiting for table level lock | INSERT INTO `catalogsearch_result` SELECT 6656 AS `query_id`, `s`.`pr oduct_id`, 0 AS `relevance` FRO | 0.000 |
| 110248 | catalog | mymagentositexxxxxx.com:56956 | catalog | Query | 932 | Waiting for table level lock | INSERT INTO `catalogsearch_result` SELECT 33220 AS `query_id`, `s`.`p roduct_id`, 0 AS `relevance` FR | 0.000 |
| 110380 | catalog | mymagentositexxxxxx.com:57095 | catalog | Query | 906 | Waiting for table level lock | INSERT INTO `catalogsearch_result` SELECT 33214 AS `query_id`, `s`.`p roduct_id`, 0 AS `relevance` FR | 0.000 |
| 110392 | catalog | mymagentositexxxxxx.com:57107 | catalog | Query | 905 | Waiting for table level lock | INSERT INTO `catalogsearch_result` SELECT 33215 AS `query_id`, `s`.`p roduct_id`, 0 AS `relevance` FR | 0.000 |
| 110810 | catalog | mymagentositexxxxxx.com:57554 | catalog | Query | 825 | Waiting for table level lock | INSERT INTO `catalogsearch_result` SELECT 6656 AS `query_id`, `s`.`pr oduct_id`, 0 AS `relevance` FRO | 0.000 |
| 110865 | catalog | mymagentositexxxxxx.com:57616 | catalog | Query | 808 | Waiting for table level lock | INSERT INTO `catalogsearch_result` SELECT 21581 AS `query_id`, `s`.`p roduct_id`, 0 AS `relevance` FR | 0.000 |
| 110968 | catalog | mymagentositexxxxxx.com:57782 | catalog | Query | 48 | update | INSERT INTO `sales_flat_quote_item` (`quote_id`, `created_at`, `updat ed_at`, `product_id`, `store_id | 0.000 |
| 110969 | catalog | mymagentositexxxxxx.com:57783 | catalog | Query | 48 | update | INSERT INTO `sales_flat_quote_item` (`quote_id`, `created_at`, `updat ed_at`, `product_id`, `store_id | 0.000 |
| 110989 | catalog | mymagentositexxxxxx.com:57803 | catalog | Query | 39 | update | INSERT INTO `sales_flat_quote_item` (`quote_id`, `created_at`, `updat ed_at`, `product_id`, `store_id | 0.000 |
| 110999 | catalog | mymagentositexxxxxx.com:57813 | catalog | Query | 34 | update | INSERT INTO `sales_flat_quote_item` (`quote_id`, `created_at`, `updat ed_at`, `product_id`, `store_id | 0.000 |
| 111012 | catalog | mymagentositexxxxxx.com:57867 | catalog | Query | 32 | update | INSERT INTO `sales_flat_quote_item` (`quote_id`, `created_at`, `updat ed_at`, `product_id`, `store_id | 0.000 |
| 111067 | catalog | mymagentositexxxxxx.com:57959 | catalog | Query | 18 | update | INSERT INTO `sales_flat_quote_item` (`quote_id`, `created_at`, `updat ed_at`, `product_id`, `store_id | 0.000 |
| 111077 | catalog | mymagentositexxxxxx.com:57974 | catalog | Query | 15 | update | INSERT INTO `sales_flat_quote_item` (`quote_id`, `created_at`, `updat ed_at`, `product_id`, `store_id | 0.000 |
| 111078 | root | localhost | NULL | Query | 0 | init | show processlist | 0.000 |
| 111117 | catalog | mymagentositexxxxxx.com:58015 | catalog | Query | 10 | Waiting for table level lock | INSERT INTO `catalogsearch_result` SELECT 13226 AS `query_id`, `s`.`p roduct_id`, 0 AS `relevance` FR | 0.000 |
| 111147 | moodle | mymagentositexxxxxx.com:58046 | moodle | Sleep | 0 | | NULL | 0.000 |
+--------+-------------+-------------------------------+---------+---------+------+------------------------------+---------------------------------------------------------------------- --------------------------------+----------+
29 rows in set (0.00 sec)
#update2
'Show create table output' of table's in waiting state is as below
MariaDB [catalog]> SHOW CREATE TABLE catalogsearch_fulltext;
+------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| catalogsearch_fulltext | CREATE TABLE `catalogsearch_fulltext` (
`product_id` int(10) unsigned NOT NULL COMMENT 'Product ID',
`store_id` smallint(5) unsigned NOT NULL COMMENT 'Store ID',
`data_index` longtext DEFAULT NULL COMMENT 'Data index',
`fulltext_id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Entity ID',
PRIMARY KEY (`fulltext_id`),
UNIQUE KEY `UNQ_CATALOGSEARCH_FULLTEXT_PRODUCT_ID_STORE_ID` (`product_id`,`store_id`),
FULLTEXT KEY `FTI_CATALOGSEARCH_FULLTEXT_DATA_INDEX` (`data_index`)
) ENGINE=MyISAM AUTO_INCREMENT=912741 DEFAULT CHARSET=utf8 COMMENT='Catalog search result table' |
+------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
MariaDB [catalog]> SHOW CREATE TABLE catalogsearch_result;
+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| catalogsearch_result | CREATE TABLE `catalogsearch_result` (
`query_id` int(10) unsigned NOT NULL COMMENT 'Query ID',
`product_id` int(10) unsigned NOT NULL COMMENT 'Product ID',
`relevance` decimal(20,4) NOT NULL DEFAULT 0.0000 COMMENT 'Relevance',
PRIMARY KEY (`query_id`,`product_id`),
KEY `IDX_CATALOGSEARCH_RESULT_QUERY_ID` (`query_id`),
KEY `IDX_CATALOGSEARCH_RESULT_PRODUCT_ID` (`product_id`),
CONSTRAINT `FK_CATALOGSEARCH_RESULT_QUERY_ID_CATALOGSEARCH_QUERY_QUERY_ID` FOREIGN KEY (`query_id`) REFERENCES `catalogsearch_query` (`query_id`) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT `FK_CATSRCH_RESULT_PRD_ID_CAT_PRD_ENTT_ENTT_ID` FOREIGN KEY (`product_id`) REFERENCES `catalog_product_entity` (`entity_id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Catalog search result table' |
+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
The process with the most time (#109997) is touching that MyISAM table? After doing SHOW FULL PROCESSLIST, I see
INSERT
INTO `catalogsearch_result`
SELECT 11474 AS `query_id`, `s`.`product_id`, 0 AS `relevance`
FROM `catalogsearch_fulltext` AS `s`
INNER JOIN `catalog_product_entity` AS `e` ON e.entity_id = s.product_id
WHERE (s.store_id = 1)
AND ((`s`.`data_index` LIKE '%Informaatika%'
OR `s`.`data_index` LIKE '%8.c%')
) ON DUPLICATE KEY
UPDATE `relevance` = VALUES(`relevance`)
That is a slow SELECT that only recently got started. Since we are talking about MyISAM, and there writes going on, the queries will happen one at a time (mostly).
It is slow because of both the OR and the leading wildcard in the LIKE test. Do you have any way to avoid both of those issues? With them there, the SELECT must scan the entire table, which apparently takes minutes. (How big is the table?)
Changing timeouts may get you past one instance, but then simply keep you in a never-ending sequence of queries waiting for other queries to finish.
The best solution is to get away from MyISAM. More tips on that: http://mysql.rjweb.org/doc.php/myisam2innodb
(Even after converting, there could be other issues.)
I'm looking to improve the speed of queries on a very large MySQL analytics table that I have. This table is tracking playercount on gameservers and the structure looks as so:
`server_tracker` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`ip` int(10) unsigned NOT NULL,
`port` smallint(5) unsigned NOT NULL,
`date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`players` tinyint(3) unsigned NOT NULL,
`map` varchar(28) NOT NULL,
`portjoin` smallint(5) NOT NULL,
PRIMARY KEY (`id`),
KEY `idx_tracking_ip_port` (`ip`,`port`)
) ENGINE=InnoDB AUTO_INCREMENT=310729056 DEFAULT CHARSET=utf8 ROW_FORMAT=FIXED |
This table is inserted into very frequently, with 10k+ servers being tracked 10+ times an hour. However, every hour the data is taken and averaged out, and put into an "averaged" table with basically the same structure.
Currently I have the IP/port setup as key. However - sometimes it can be a tad slow when doing that hourly averaging - so I am curious if it would be worth putting an index on the timestamp, which is frequently used to select data from a certain timeframe like so:
SELECT `players`
FROM `server_tracker`
WHERE `ip` = x
AND `port` = x
AND `date` > NOW()
AND `date` < NOW() + INTERVAL 60 MINUTE
ORDER BY `id` DESC
This is the only type of query ran on this table. The table is only used for fetching the playercount from gameservers within a specific timeframe. The data is never updated or changed.
However, I am a bit new to all of this - and I am not sure if putting an index on the timestamp would do much of anything. Just looking for some friendly advice.
Results of EXPLAIN SELECT players FROM server_tracker WHERE ip = x AND port = x AND date > NOW() AND date < NOW() + INTERVAL 60 MINUTE ORDER BY id DESC
+----+-------------+-----------------+------+----------------------+----------------------+---------+-------------+-------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-----------------+------+----------------------+----------------------+---------+-------------+-------+-------------+
| 1 | SIMPLE | server_tracker | ref | idx_tracking_ip_port | idx_tracking_ip_port | 6 | const,const | 15354 | Using where |
+----+-------------+-----------------+------+----------------------+----------------------+---------+-------------+-------+-------------+
One of the most important information in MySQL and scripts is to know the MySQL to very few exceptions, always just ONE INDEX can be used in a query.
So it does not use much depending on an index ever to set a Column when all 4 are used verfelder in the where clause.
Only a combined index hilt over these fields.
The order of the fields is very important for this index can also be used for other queries.
An example:
An index on field1, field2 and field3 is used when you have the WHERE FIELD1 or FIELD1 and FIELD2 or field1, field2 and FIELD3. This index is not used if you in the WHERE FIELD2 or used FIELD3 or FIELD2 and field. 3 So always use the first field.
Too easy to find out if un like the QUERY works you can just run your query and EXPALIN and beommst directly the information whether and which index is used. If there are several lines you can as an indicator, the individual values under rows muliplizieren together. The smaller this number is the better performs your query.
MariaDB [tmp]> EXPLAIN select * from content;
+------+-------------+---------+------+---------------+------+---------+------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+---------+------+---------------+------+---------+------+------+-------+
| 1 | SIMPLE | content | ALL | NULL | NULL | NULL | NULL | 13 | |
+------+-------------+---------+------+---------------+------+---------+------+------+-------+
1 row in set (0.00 sec)
MariaDB [tmp]>
Anternativ you can check out the profiler how long the QUERY in what capacity depends and about optimizing server
An example:
MariaDB [(none)]> use tmp
Database changed
MariaDB [tmp]> SET PROFILING=ON;
Query OK, 0 rows affected (0.00 sec)
MariaDB [tmp]>
MariaDB [tmp]> SELECT * FROM content;
+----+------+---------------------+--------+------+--------------+------+------+------+------+
| id | Wert | Zeitstempel | WertID | aaa | d | e | wwww | n | ddd |
+----+------+---------------------+--------+------+--------------+------+------+------+------+
| 1 | 10 | 2001-01-01 00:00:00 | 1 | NULL | 1.5000 | NULL | NULL | 1 | NULL |
| 2 | 12.3 | 2001-01-01 00:01:00 | 2 | NULL | 2.5000 | NULL | NULL | 2 | NULL |
| 3 | 17.4 | 2001-01-01 00:02:00 | 3 | NULL | 123456.1250 | NULL | NULL | 3 | NULL |
| 4 | 10.9 | 2001-01-01 01:01:00 | 1 | NULL | 1000000.0000 | NULL | NULL | 4 | NULL |
| 5 | 15.4 | 2001-01-01 01:02:00 | 2 | NULL | NULL | NULL | NULL | 5 | NULL |
| 6 | 20.9 | 2001-01-01 01:03:00 | 3 | NULL | NULL | NULL | NULL | 6 | NULL |
| 7 | 22 | 2001-01-02 00:00:00 | 1 | NULL | NULL | NULL | NULL | 7 | NULL |
| 8 | 12.3 | 2001-01-02 00:01:00 | 2 | NULL | NULL | NULL | NULL | 8 | NULL |
| 9 | 17.4 | 2001-01-02 00:02:00 | 3 | NULL | NULL | NULL | NULL |
+----+------+---------------------+--------+------+--------------+------+------+------+------+
13 rows in set (0.00 sec)
MariaDB [tmp]>
MariaDB [tmp]> SHOW PROFILE;
+----------------------+----------+
| Status | Duration |
+----------------------+----------+
| starting | 0.000031 |
| checking permissions | 0.000005 |
| Opening tables | 0.000036 |
| After opening tables | 0.000004 |
| System lock | 0.000003 |
| Table lock | 0.000002 |
| After opening tables | 0.000005 |
| init | 0.000013 |
| optimizing | 0.000006 |
| statistics | 0.000013 |
| preparing | 0.000010 |
| executing | 0.000002 |
| Sending data | 0.000073 |
| end | 0.000003 |
| query end | 0.000003 |
| closing tables | 0.000006 |
| freeing items | 0.000003 |
| updating status | 0.000012 |
| cleaning up | 0.000003 |
+----------------------+----------+
19 rows in set (0.00 sec)
MariaDB [tmp]>