sql数据库查询网站模板(sql查询平台)

2024-02-24 08:10:13 分类：杂七乱八 热度：33 评论： 1

　　导读

　　在分页功能开发时，我们很习惯用 LIMIT O,N 的方法来取数据。这种方法在遇到超大分页偏移量时是会把 MySQL 搞死的，请别再这么写 SQL 了

本文约 2000 字，阅读时间 10 分钟

　　通常，我们会采用 ORDER BY LIMIT start, offset 的方式来进行分页查询。例如下面这个 SQL：

　　SELECT * FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 100, 10;

　　或者像下面这个不带任何条件的分页SQL：

　　SELECT * FROM `t1` ORDER BY id DESC LIMIT 100, 10;

　　一般而言，分页 SQL 的耗时随着 start 值的增加而急剧增加，我们来看下面这 2 个不同起始值的分页 SQL 执行耗时：

　　yejr@imysql.com> SELECT * FROM `t1` WHERE ftype=1

　　ORDER BY id DESC LIMIT 500, 10;

　　…

　　10 rows in set (0.05 sec)

　　yejr@imysql.com> SELECT * FROM `t1` WHERE ftype=6

　　ORDER BY id DESC LIMIT 935500, 10;

　　…

　　10 rows in set (2.39 sec)

　　可以看到，随着分页数量的增加，SQL 查询耗时也有数十倍增加，显然不科学。

　　今天我们就来分析下，如何能优化这个分页方案。

　　一般滴，想要优化分页的终极方案就是：没有分页，哈哈哈~~~，不要说我讲废话，确实如此，可以把分页算法交给 Solr、Lucene、Sphinx 等第三方解决方案，尤其是遇到有模糊搜索的需求时，没必要让 MySQL 来做它不擅长的事情。

　　当然了，有小伙伴说，用第三方太麻烦了，我们就想用 MySQL 来做这个分页，咋办呢？莫急，且待我们慢慢分析。

　　先看下表 DDL、数据量、查询 SQL 的执行计划等信息：

　　yejr@imysql.com> SHOW CREATE TABLE `t1`;

　　CREATE TABLE `t1` (

　　`id` int(10) unsigned NOT NULL AUTO_INCREMENT,

　　...

　　`ftype` tinyint(3) unsigned NOT NULL,

　　...

　　PRIMARY KEY (`id`)

　　) ENGINE=InnoDB DEFAULT CHARSET=utf8;

　　yejr@imysql.com> select count(*) from t1;

　　+----------+

　　| count(*) |

　　+----------+

　　| 994584 |

　　+----------+

　　yejr@imysql.com> EXPLAIN SELECT * FROM `t1` WHERE ftype=1

　　ORDER BY id DESC LIMIT 500, 10G

　　*************************** 1. row ***************************

　　id: 1

　　select_type: SIMPLE

　　table: t1

　　type: index

　　possible_keys: NULL

　　key: PRIMARY

　　key_len: 4

　　ref: NULL

　　rows: 510

　　Extra: Using where

　　yejr@imysql.com> EXPLAIN SELECT * FROM `t1` WHERE ftype=1

　　ORDER BY id DESC LIMIT 935500, 10G

　　*************************** 1. row ***************************

　　id: 1

　　select_type: SIMPLE

　　table: t1

　　type: index

　　possible_keys: NULL

　　key: PRIMARY

　　key_len: 4

　　ref: NULL

　　rows: 935510

　　Extra: Using where

　　可以看到，虽然是通过主键索引扫描数据的，但第二个 SQL 需要扫描的记录数太大了，而且需要先扫描约 935510 条记录，然后再根据排序结果取 10 条记录，这肯定是非常慢了。

　　针对这种情况，我们的优化思路就比较清晰了，有两点：

尽可能从索引中直接获取数据，避免或减少再次扫描行数据的次数（也就是我们通常所说的避免回表）；

尽可能减少扫描的记录数，也就是先确定起始的范围，再往后取N条记录。

　　根据上面这两种优化思路，有相应的 SQL 改写方法：子查询、表连接，像下面这样的：

　　方法一

采用子查询的方式优化，在子查询里先从索引获取到最大 ID，然后倒序排，再取 10 行结果集

注意这里采用了两次倒序排，因此在取 LIMIT 的 start 值时，比原来的值加了 10，即 935510，否则结果将和原来的不一致

　　yejr@imysql.com> EXPLAIN SELECT * FROM (SELECT * FROM `t1` WHERE

　　id > ( SELECT id FROM `t1` WHERE ftype=1

　　ORDER BY id DESC LIMIT 935510, 1) LIMIT 10) t ORDER BY id DESCG

　　*************************** 1. row ***************************

　　id: 1

　　select_type: PRIMARY

　　table: <derived2>

　　type: ALL

　　possible_keys: NULL

　　key: NULL

　　key_len: NULL

　　ref: NULL

　　rows: 10

　　Extra: Using filesort

　　*************************** 2. row ***************************

　　id: 2

　　select_type: DERIVED

　　table: t1

　　type: ALL

　　possible_keys: PRIMARY

　　key: NULL

　　key_len: NULL

　　ref: NULL

　　rows: 973192

　　Extra: Using where

　　*************************** 3. row ***************************

　　id: 3

　　select_type: SUBQUERY

　　table: t1

　　type: index

　　possible_keys: NULL

　　key: PRIMARY

　　key_len: 4

　　ref: NULL

　　rows: 935511

　　Extra: Using where

　　方法二

采用 INNER JOIN 优化，JOIN 子句里也优先从索引获取 ID 列表，然后直接关联查询获得最终结果，这里不需要加 10

　　yejr@imysql.com> EXPLAIN SELECT * FROM `t1` INNER JOIN

　　( SELECT id FROM `t1` WHERE ftype=1

　　ORDER BY id DESC LIMIT 935500,10) t2 USING (id)G

　　*************************** 1. row ***************************

　　id: 1

　　select_type: PRIMARY

　　table: <derived2>

　　type: ALL

　　possible_keys: NULL

　　key: NULL

　　key_len: NULL

　　ref: NULL

　　rows: 935510

　　Extra: NULL

　　*************************** 2. row ***************************

　　id: 1

　　select_type: PRIMARY

　　table: t1

　　type: eq_ref

　　possible_keys: PRIMARY

　　key: PRIMARY

　　key_len: 4

　　ref: t2.id

　　rows: 1

　　Extra: NULL

　　*************************** 3. row ***************************

　　id: 2

　　select_type: DERIVED

　　table: t1

　　type: index

　　possible_keys: NULL

　　key: PRIMARY

　　key_len: 4

　　ref: NULL

　　rows: 973192

　　Extra: Using where

　　然后来对比下这 2 个优化后的执行时间/代价：

　　1. 子查询优化：从 profiling 的结果来看，相比原来耗时减少 28.2%

　　yejr@imysql.com> SELECT * FROM (SELECT * FROM `t1` WHERE

　　id > ( SELECT id FROM `t1` WHERE ftype=1

　　ORDER BY id DESC LIMIT 935510, 1) LIMIT 10) T ORDER BY id DESC;

　　...

　　rows in set (1.86 sec)

　　2. INNER JOIN优化：从 profiling 的结果来看，相比原来耗时减少30.8%

　　yejr@imysql.com> SELECT * FROM `t1` INNER JOIN

　　( SELECT id FROM `t1` WHERE ftype=1

　　ORDER BY id DESC LIMIT 935500,10) t2 USING (id);

　　...

　　10 rows in set (1.83 sec)

　　再来看一个不带过滤条件的分页 SQL 对比：

　　1. 原始SQL

　　yejr@imysql.com> EXPLAIN SELECT * FROM `t1` ORDER BY id DESC LIMIT 935500, 10G

　　*************************** 1. row ***************************

　　id: 1

　　select_type: SIMPLE

　　table: t1

　　type: index

　　possible_keys: NULL

　　key: PRIMARY

　　key_len: 4

　　ref: NULL

　　rows: 935510

　　Extra: NULL

　　yejr@imysql.com> SELECT * FROM `t1` ORDER BY id DESC LIMIT 935500, 10;

　　...

　　10 rows in set (2.22 sec)

　　2. 采用子查询优化，相比原来耗时减少 10.6%

　　yejr@imysql.com> EXPLAIN SELECT * FROM (SELECT * FROM `t1` WHERE

　　id > ( SELECT id FROM `t1` ORDER BY id DESC

　　LIMIT 935510, 1) LIMIT 10) t ORDER BY id DESC;

　　*************************** 1. row ***************************

　　id: 1

　　select_type: PRIMARY

　　table: <derived2>

　　type: ALL

　　possible_keys: NULL

　　key: NULL

　　key_len: NULL

　　ref: NULL

　　rows: 10

　　Extra: Using filesort

　　*************************** 2. row ***************************

　　id: 2

　　select_type: DERIVED

　　table: t1

　　type: ALL

　　possible_keys: PRIMARY

　　key: NULL

　　key_len: NULL

　　ref: NULL

　　rows: 973192

　　Extra: Using where

　　*************************** 3. row ***************************

　　id: 3

　　select_type: SUBQUERY

　　table: t1

　　type: index

　　possible_keys: NULL

　　key: PRIMARY

　　key_len: 4

　　ref: NULL

　　rows: 935511

　　Extra: Using index

　　yejr@imysql.com> SELECT * FROM (SELECT * FROM `t1` WHERE

　　id > ( SELECT id FROM `t1` ORDER BY id DESC

　　LIMIT 935510, 1) LIMIT 10) t ORDER BY id DESC;

　　…

　　10 rows in set (2.01 sec)

　　3. 采用INNER JOIN优化，相比原来耗时减少 30.2%

　　yejr@imysql.com> EXPLAIN SELECT * FROM `t1` INNER JOIN

　　( SELECT id FROM `t1`ORDER BY id DESC

　　LIMIT 935500,10) t2 USING (id)G

　　*************************** 1. row ***************************

　　id: 1

　　select_type: PRIMARY

　　table:

　　type: ALL

　　possible_keys: NULL

　　key: NULL

　　key_len: NULL

　　ref: NULL

　　rows: 935510

　　Extra: NULL

　　*************************** 2. row ***************************

　　id: 1

　　select_type: PRIMARY

　　table: t1

　　type: eq_ref

　　possible_keys: PRIMARY

　　key: PRIMARY

　　key_len: 4

　　ref: t1.id

　　rows: 1

　　Extra: NULL

sql数据库查询网站模板(sql查询平台),sql数据库查询网站模板(sql查询平台),sql数据库查询网站模板,第1张

　　*************************** 3. row ***************************

　　id: 2

　　select_type: DERIVED

　　table: t1

　　type: index

　　possible_keys: NULL

　　key: PRIMARY

　　key_len: 4

　　ref: NULL

　　rows: 973192

　　Extra: Using index

　　yejr@imysql.com> SELECT * FROM `t1` INNER JOIN

　　( SELECT id FROM `t1`ORDER BY id DESC

　　LIMIT 935500,10) t2 USING (id);

　　…

　　10 rows in set (1.70 sec)

　　至此，我们看到采用子查询或者 INNER JOIN 进行优化后，都有大幅度的提升，这个方法也同样适用于较小的分页。

　　说下结论，子查询和 INNER JOIN 分页优化方法的提升效率是：

带 WHERE 条件的分页分别能提高查询效率：24.9%、156.5%；

不带 WHERE 条件的分页分别提高查询效率：554.5%、11.7%。

　　单从提升比例说，还是挺可观的。而且这两种优化方法基本上可适用于各种分页模式，强烈建议一开始就改成这种 SQL 写法习惯。

　　我们来看下各种场景相应的提升比例是多少：

　　这样看就和明显了，尤其是针对大分页的情况，因此我们优先推荐使用 INNER JOIN 方式优化分页算法。

　　上述每次测试都重启 mysqld 实例，并且加了 SQL_NO_CACHE，以保证每次都是直接数据文件或索引文件中读取。如果数据经过预热后，查询效率会一定程度提升，但上述相应的效率提升比例还是基本一致的。

　　作者： 叶金荣

　　来源：公众号『 老叶茶馆』

　　广 告

1、本网站名称：源码村资源网
2、本站永久网址：https://www.yuanmacun.com
3、本网站的文章部分内容可能来源于网络，仅供大家学习与参考，如有侵权，请联系站长进行删除处理。
4、本站一切资源不代表本站立场，并不代表本站赞同其观点和对其真实性负责。
5、本站一律禁止以任何方式发布或转载任何违法的相关信息，访客发现请向站长举报
6、本站资源大多存储在云盘，如发现链接失效，请联系我们我们会第一时间更新。
源码村资源网 » sql数据库查询网站模板(sql查询平台)
源码村长

源码村长

分享到：

1 评论

您需要 登录账户 后才能发表评论

发表评论

欢迎 访客 发表评论