Sucker made mistakes, really feel this!
NOT IN NOT EXISTS optimized to the performance by 10%, to deploy a new server after a certain amount of data accumulated to a total number discovered a problem: 80w large amount of data tables (cookie_clean_t) less than 1w amount of data associated with a temporary table (cookie_short_run_t) provided a large part of the interface request print time-consuming to achieve even more than 5s 4s, 3s request timeout setting is very passive! Was the first reaction is to see the index, have read several times to confirm the normal index creation, last Baidu optimization NOT EXISTS demand solution, then find a LEFT JOIN design, test and finally found worse performance.
Secondary optimized SQL statement is as follows:
EXPLAIN
SELECT * FROM cookie_clean_t cc
LEFT JOIN cookie_short_run_t csr ON cc.uuid=csr.uuid
WHERE cc.state=0 AND csr.uuid IS NULL
ORDER BY cc.uuid DESC LIMIT 50
EXPLAIN
SELECT * FROM cookie_clean_t cc
WHERE NOT EXISTS(SELECT csr.uuid FROM cookie_short_run_t csr WHERE csr.uuid=cc.uuid)
AND cc.state=0
ORDER BY cc.uuid DESC LIMIT 50
As more business logic associated with processing of the table, was also taken into account temporary table Bulk update status affects the large table optimized SQL statements, exclude all possible, and finally confirmed again found cookie_short_run_t index fields uuid not create the index, after adding performance upgrade 55%.
But also pay for his negligence, pig head really deserve it!