标签:条件查询 结果 创建 临时 insert 优化方案 span pre 方法
假设有如下SQL语句:
SELECT * FROM table1 LIMIT offset, rows
这是一条典型的LIMIT语句,常见的使用场景是,某些查询返回的内容特别多,而客户端处理能力有限,希望每次只取一部分结果进行处理。
上述SQL语句的实现机制是:
这种实现机制存在一个弊端:虽然只需要返回rows行记录,但却必须先访问offset行不会用到的记录。对一张数据量很大的表进行查询时,offset值可能非常大,此时limit语句的效率就非常低了。
假设表message表中有10万行记录,每次取1000条。
优化前:
SELECT message.* FROM message LIMIT 0,1000
SELECT message.* FROM message LIMIT 1000,1000
SELECT message.* FROM message LIMIT 2000,1000
……
SELECT message.* FROM message LIMIT 998000,1000
SELECT message.* FROM message LIMIT 999000,1000
优化后(利用自增主键,避免offset的使用):
SELECT message.* FROM message WHERE uid>0 LIMIT 1000
SELECT message.* FROM message WHERE uid>1000 LIMIT 1000
SELECT message.* FROM message WHERE uid>2000 LIMIT 1000
……
SELECT message.* FROM message WHERE uid>998000 LIMIT 1000
SELECT message.* FROM message WHERE uid>999000 LIMIT 1000
在笔者的机器上,优化前,SQL语句从前往后越来越慢(最后一条语句执行了150毫秒),而优化后,每条语句的耗时都是微妙级的。
实际工程中遇到的查询,通常要复杂些,比如,多表查询、条件查询。这种情况下,查询结果通常不是按照自增主键的顺序逐一排列的。
例如,对于下述SQL语句,就不能像第二节那样优化了:
SELECT timerec FROM message WHERE evttype = 1 AND nodename = ‘node1‘
LIMIT 0,1000
……
SELECT timerec FROM message WHERE evttype = 1 AND nodename = ‘node1‘
LIMIT 999000,1000
……
优化方案:建立临时表(含自增主键)存储数十万行的查询结果,之后用第二节的方法分多次访问临时表、获取数据。
CREATE TEMPORARY TABLE tmp_timerec(
`uid` bigint(20) NOT NULL AUTO_INCREMENT,
`timerec` datetime NOT NULL,
PRIMARY KEY (`uid`))
INSERT INTO tmp_timerec
SELECT null,timerec FROM message
WHERE evttype = 1 AND nodename = ‘node1’
SELECT timerec FROM tmp_timerec where uid > 0 LIMIT 1000
……
SELECT timerec FROM tmp_timerec where uid > 999000 LIMIT 1000
标签:条件查询 结果 创建 临时 insert 优化方案 span pre 方法
原文地址:https://www.cnblogs.com/AluoKa/p/10884150.html