在不是服务器性能影响的时候，可以关注以下：
1、通过explain查看sql的执行计划，看是否用到了索引
2、是否sql写的不合理，需要改写sql等
3、还是sql没有问题，索引也合理，就是数据太大，字段太多引起查询慢，这个就可以考虑是不是改分表或者分开啥的。
优化这一块涉及到的比较多，可以多重网上，或者博客看看总结，对比你的情况去优化如何提高MySQL Limit查询的性能\x0d\在MySQL数据库 *** 作中，我们在做一些查询的时候总希望能避免数据库引擎做全表扫描，因为全表扫描时间长，而且其中大部分扫描对客户端而言是没有意义的。其实我们可以使用Limit关键字来避免全表扫描的情况，从而提高效率。\x0d\有个几千万条记录的表 on MySQL 50x，现在要读出其中几十万万条左右的记录。常用方法，依次循环： \x0d\select from mytable where index_col = xxx limit offset, limit; \x0d\\x0d\经验：如果没有blob/text字段，单行记录比较小，可以把 limit 设大点，会加快速度。\x0d\问题：头几万条读取很快，但是速度呈线性下降，同时 mysql server cpu 99% ，速度不可接受。 \x0d\调用 explain select from mytable where index_col = xxx limit offset, limit; \x0d\显示 type = ALL \x0d\在 MySQL optimization 的文档写到"All"的解释 \x0d\A full table scan is done for each combination of rows from the previous tables This is normally not good if the table is the first table not marked const, and usually very bad in all other cases Normally, you can avoid ALL by adding indexes that allow row retrieval from the table based on constant values or column values from earlier tables \x0d\看样子对于 all, mysql 就使用比较笨的方法，那就改用 range 方式？ 因为 id 是递增的，也很好修改 sql 。\x0d\select from mytable where id > offset and id SELECT FROM table LIMIT 5,10; //检索记录行6-15\x0d\\x0d\//为了检索从某一个偏移量到记录集的结束所有的记录行，可以指定第二个参数为-1\x0d\mysql> SELECT FROM table LIMIT 95,-1; //检索记录行96-last\x0d\\x0d\//如果只给定一个参数，它表示返回最大的记录行数目，换句话说，LIMIT n 等价于 LIMIT 0,n\x0d\mysql> SELECT FROM table LIMIT 5; //检索前5个记录行\x0d\\x0d\MySQL的limit给分页带来了极大的方便，但数据量一大的时候，limit的性能就急剧下降。同样是取10条数据，下面两句就不是一个数量级别的。\x0d\select from table limit 10000,10\x0d\select from table limit 0,10\x0d\\x0d\文中不是直接使用limit，而是首先获取到offset的id然后直接使用limit size来获取数据。根据他的数据，明显要好于直接使用limit。\x0d\这里我具体使用数据分两种情况进行测试。\x0d\1、offset比较小的时候：\x0d\select from table limit 10,10 \x0d\//多次运行，时间保持在00004-00005之间\x0d\Select From table Where vid ＞=(Select vid From table Order By vid limit 10,1) limit 10 \x0d\//多次运行，时间保持在00005-00006之间，主要是00006\x0d\\x0d\结论：偏移offset较小的时候，直接使用limit较优。这个显然是子查询的原因。\x0d\2、offset大的时候：\x0d\select from table limit 10000,10 \x0d\//多次运行，时间保持在00187左右\x0d\\x0d\Select From table Where vid ＞=(Select vid From table Order By vid limit 10000,1) limit 10\x0d\//多次运行，时间保持在00061左右，只有前者的1/3。可以预计offset越大，后者越优。1首先我的表默认是:innoDB,这种表的类型不支持全文检索，所以要先改变其类型为MyISAM。
alter news_info title engine=MyISAM;
2然后要在对应的要进行查找的字段上面建立全文检索的索引：
alter news_info add fulltext index(title);
如果要同时对多个字段进行检索可以这样:优化方案：
主从同步+读写分离：
这个表在有设备条件的情况下，读写分离，这样能减少很多压力，而且数据稳定性也能提高
纵向分表：
根据原则，每个表最多不要超过5个索引，纵向拆分字段，将部分字段拆到一个新表
通常我们按以下原则进行垂直拆分:（先区分这个表中的冷热数据字段）
把不常用的字段单独放在一张表;
把text，blob等大字段拆分出来放在附表中;
经常组合查询的列放在一张表中;
缺点是：很多逻辑需要重写，带来很大的工作量。
利用表分区：
这个是推荐的一个解决方案，不会带来重写逻辑等，可以根据时间来进行表分区，相当于在同一个磁盘上，表的数据存在不同的文件夹内，能够极大的提高查询速度。
横向分表：
1000W条数据不少的，会带来一些运维压力，备份的时候，单表备份所需时间会很长，所以可以根据服务器硬件条件进行水平分表，每个表有多少数据为准。
在开始演示之前，我们先介绍下两个概念。
概念一，数据的可选择性基数，也就是常说的cardinality值。
查询优化器在生成各种执行计划之前，得先从统计信息中取得相关数据，这样才能估算每步 *** 作所涉及到的记录数，而这个相关数据就是cardinality。简单来说，就是每个值在每个字段中的唯一值分布状态。
比如表t1有100行记录，其中一列为f1。f1中唯一值的个数可以是100个，也可以是1个，当然也可以是1到100之间的任何一个数字。这里唯一值越的多少，就是这个列的可选择基数。
那看到这里我们就明白了，为什么要在基数高的字段上建立索引，而基数低的的字段建立索引反而没有全表扫描来的快。当然这个只是一方面，至于更深入的探讨就不在我这篇探讨的范围了。
概念二，关于HINT的使用。
这里我来说下HINT是什么，在什么时候用。
HINT简单来说就是在某些特定的场景下人工协助MySQL优化器的工作，使她生成最优的执行计划。一般来说，优化器的执行计划都是最优化的，不过在某些特定场景下，执行计划可能不是最优化。
比如：表t1经过大量的频繁更新 *** 作，（UPDATE,DELETE,INSERT），cardinality已经很不准确了，这时候刚好执行了一条SQL，那么有可能这条SQL的执行计划就不是最优的。为什么说有可能呢？
来看下具体演示
譬如，以下两条SQL，
A：
select from t1 where f1 = 20;B：
select from t1 where f1 = 30;如果f1的值刚好频繁更新的值为30，并且没有达到MySQL自动更新cardinality值的临界值或者说用户设置了手动更新又或者用户减少了sample page等等，那么对这两条语句来说，可能不准确的就是B了。
这里顺带说下，MySQL提供了自动更新和手动更新表cardinality值的方法，因篇幅有限，需要的可以查阅手册。
那回到正题上，MySQL 80 带来了几个HINT，我今天就举个index_merge的例子。
示例表结构：
mysql> desc t1;+------------+--------------+------+-----+---------+----------------+| Field | Type | Null | Key | Default | Extra |+------------+--------------+------+-----+---------+----------------+| id | int(11) | NO | PRI | NULL | auto_increment || rank1 | int(11) | YES | MUL | NULL | || rank2 | int(11) | YES | MUL | NULL | || log_time | datetime | YES | MUL | NULL | || prefix_uid | varchar(100) | YES | | NULL | || desc1 | text | YES | | NULL | || rank3 | int(11) | YES | MUL | NULL | |+------------+--------------+------+-----+---------+----------------+7 rows in set (000 sec)表记录数：
这里我们两条经典的SQL：
SQL C：
select from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2;SQL D：
select from t1 where rank1 =100 and rank2 =100 and rank3 =100;表t1实际上在rank1,rank2,rank3三列上分别有一个二级索引。
那我们来看SQL C的查询计划。
显然，没有用到任何索引，扫描的行数为32034，cost为324365。
mysql> explain format=json select from t1 where rank1 =1 or rank2 = 2 or rank3 = 2\G 1 row EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "324365" }, "table": { "table_name": "t1", "access_type": "ALL", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "rows_examined_per_scan": 32034, "rows_produced_per_join": 115, "filtered": "036", "cost_info": { "read_cost": "323207", "eval_cost": "1158", "prefix_cost": "324365", "data_read_per_join": "49K" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt``t1``rank1` = 1) or (`ytt``t1``rank2` = 2) or (`ytt``t1``rank3` = 2))" } }}1 row in set, 1 warning (000 sec)我们加上hint给相同的查询，再次看看查询计划。
这个时候用到了index_merge,union了三个列。扫描的行数为1103，cost为44109，明显比之前的快了好几倍。
mysql> explain format=json select /+ index_merge(t1) / from t1 where rank1 =1 or rank2 = 2 or rank3 = 2\G 1 row EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "44109" }, "table": { "table_name": "t1", "access_type": "index_merge", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "key": "union(idx_rank1,idx_rank2,idx_rank3)", "key_length": "5,5,5", "rows_examined_per_scan": 1103, "rows_produced_per_join": 1103, "filtered": "10000", "cost_info": { "read_cost": "33079", "eval_cost": "11030", "prefix_cost": "44109", "data_read_per_join": "473K" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt``t1``rank1` = 1) or (`ytt``t1``rank2` = 2) or (`ytt``t1``rank3` = 2))" } }}1 row in set, 1 warning (000 sec)我们再看下SQL D的计划：
不加HINT，
mysql> explain format=json select from t1 where rank1 =100 and rank2 =100 and rank3 =100\G 1 row EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "53434" }, "table": { "table_name": "t1", "access_type": "ref", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "key": "idx_rank1", "used_key_parts": [ "rank1" ], "key_length": "5", "ref": [ "const" ], "rows_examined_per_scan": 555, "rows_produced_per_join": 0, "filtered": "007", "cost_info": { "read_cost": "47884", "eval_cost": "004", "prefix_cost": "53434", "data_read_per_join": "176" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt``t1``rank3` = 100) and (`ytt``t1``rank2` = 100))" } }}1 row in set, 1 warning (000 sec)加了HINT，
mysql> explain format=json select /+ index_merge(t1)/ from t1 where rank1 =100 and rank2 =100 and rank3 =100\G 1 row EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "523" }, "table": { "table_name": "t1", "access_type": "index_merge", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "key": "intersect(idx_rank1,idx_rank2,idx_rank3)", "key_length": "5,5,5", "rows_examined_per_scan": 1, "rows_produced_per_join": 1, "filtered": "10000", "cost_info": { "read_cost": "513", "eval_cost": "010", "prefix_cost": "523", "data_read_per_join": "440" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt``t1``rank3` = 100) and (`ytt``t1``rank2` = 100) and (`ytt``t1``rank1` = 100))" } }}1 row in set, 1 warning (000 sec)对比下以上两个，加了HINT的比不加HINT的cost小了100倍。
总结下，就是说表的cardinality值影响这张的查询计划，如果这个值没有正常更新的话，就需要手工加HINT了。相信MySQL未来的版本会带来更多的HINT。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）