【20180329】MySQL优化SQL一则以及思考

线网环境

  1. MySQL 5.6.21-log MySQL Community Server
  2. innodb_buffer_pool_size 1G
  3. 关闭QC
  4. 表存在分区

表结构和待优化的SQL

mysql> show create table articles \G
*************************** 1. row ***************************
       Table: articles
Create Table: CREATE TABLE `articles` (
  `id` int(11) NOT NULL,
  `user_id` int(11) NOT NULL,
  `pic_urls` varchar(512) NOT NULL,
  `vote_id` int(11) NOT NULL DEFAULT ‘0‘,
  `topic_id` int(11) NOT NULL DEFAULT ‘0‘,
  `type` int(11) NOT NULL,
  `content` varchar(3000) DEFAULT NULL,
  `location` varchar(32) NOT NULL DEFAULT ‘‘,
  `longitude` varchar(12) NOT NULL,
  `latitude` varchar(12) NOT NULL,
  `status` int(11) NOT NULL,
  `created_at` datetime NOT NULL,
  `user_ip` int(11) unsigned NOT NULL DEFAULT ‘0‘,
  `review` tinyint(4) NOT NULL DEFAULT ‘0‘,
  PRIMARY KEY (`id`),
  KEY `topic_id` (`topic_id`),
  KEY `user_id` (`user_id`,`status`,`created_at`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
/*!50100 PARTITION BY HASH (id)
PARTITIONS 16 */
SELECT COUNT(1) AS c FROM articles WHERE topic_id = 114 AND status = 1 AND id NOT IN (17080670,17079098,17109846,17110577,17126923,17117892)  AND user_id NOT IN (33824249,33828294,32833143,33834489,33841022,33841121,33841156,33844937,33847129,33827047,33848560,32720750,33833941,33848573,33810491,33838021,33847010,33851748,33853093,33853111,33853156,33841943,33853408,33857041,33854233,33846742,33846748,33854255,33857064,33885581,33864476,33934278,34280131,34185367,34280088,34346710,34385075,34385237,34077681,34280171,34346732,34346738,34332490,34335274,34181694,34386339,34250847,34346757,34346752,34346813,34346945,7490639,34346927,34010356,34347049,33940626,34341461,34347061,34347081,34341381,34347085,34347126,34332537,34347117,34394447,34327303,31607732,34173783,34353368,34353330,34150466,34070811,34353413,34353371,34392543,34110905,34332506,34353421,34068582,34368645,33711510,34353619,33888980,34353584,34353617,34366773,34068768,34367479,34370650,34353698,34353721,34360131,34360154,34237758,34366508,34360254,34360246,34376763,34360248,34360276,33965629,34360269,34392397,34327406,34360307,34360402,34360431,27855780,34360467,34029547,34360448,34392561,34360453,34397244,34453559,34453531,34360480,34224620,34397270,34340166,34453534,34462520,1060754,34070596,34335225,33464686,34360505,34360611,34413592,20244349,34367391,34367528,34367558,34496904,34494346,32992426,34367521,34367506,34397284,34075167,34397236,34367508,34502838,34367511,34367671,34367672,34256721,34510895,34511335,34220701,34511556,34370188,34520818,34521120,34521121,34521099,34452468,34530058,34534558,34533294,34541331,34060856,34543797,34082416,34500366,34545190,34515713,34417773,34367802,34553311,34367862,34367832,34127282,34083939,33691298,34373694,34559793,34373689,34545953,34373783,34500833,34573568,34525236,34576425,34373688,34585516,34415308,13164849,34574639,34568298,34558301,34583203,34580301,12135076,5485129,34574974,34552389,34567808,34589428,34586104,34596708,34587929,34589613,34592242,32710709,33996135,34589622,34590003,34579522,34603444,33471864,34104130,34494174,34026755,34335083,34637732,34608155,31270655,34313290,34373760,34373757,32717182,34396802,32568247,31832477,34210659,34653651,34653681,34102064,34414116,34422038,34574228,34422010,34584690,34156339,34422218,34413816,34413818,34554514,30371762,34405772,34397948,34398306,33934125,34404648,34085531,34670672,32578081,34633739,34768345,34454576,34093578,34671375,34790367,34369280,34799915,34799934,34791716,34791710,34791767,34169856,34911914,34887431,34887393,34853976,34915775,34993982,34961184,34993983,35005710,34913662,32555445,35093709,35097894,35146899,35147077,35170956,31163038,33971212,35160092,35183839,35256282,35196189,34399233,35092356,34405546,35168649,31809004,35270433,35168810,35666711,35300151,35710861,18054773,35905428,35534509,35301706,35741153,35367969,30990616,3204057,35970676,33681952,35970746,35369209,35369417,35985122,36020270,35900701,9316493,35553853,35633504,35633617,36232496,35191850,35880221,36415016,36296697,36529238,35786342,36659949,36405256,36422717,36661338,36661297,36614751,36440561,35861881,14752030,32736870,36458571,36689504,36461801,36795506,36796410,37054128,37054123,37054054,37054399,37074768,37090630,37090391,36680809,37231542,37110709,36681004,37158764,37158828,37158887,37167540,37167539,37175339,37175275,37175465,37279948,32873902,37286818,37317499,37345029,37344970,4222498,36483504);

优化思路

  1. 第一次: 在topic_id和status上面添加联合索引。

    • 创建联合索引在topic_id status
    • 查看SQL的执行计划
    • SQL第一次请求耗时
    • SQL第二次请求耗时
  2. 第二次:在topic_id,status和id上面添加联合索引。
    • 创建联合索引在 topic_id status id
    • 查看SQL的执行计划
    • 第一次SQL请求耗时
    • 第二次SQL请求耗时
  3. 在topic_id,status,id和user_id上面创建联合索引
    • 创建联合索引 topic_id status id user_id
    • 查看SQL执行计划
    • 第一次SQL请求耗时
    • 第二次SQL请求耗时
  4. 第四次: 在topic_id,status和user_id上面创建联合索引
    • 创建联合索引 topic_id status user_id
    • 查看SQL执行计划
    • 第一次SQL请求耗时
    • 第二次SQL请求耗时

思考

  1. 第一次和第二次优化和第三次,第四次的优化为什么相差那么大?

    • 主要原因是因为第一次和第二次优化user_id的键值数据需要回表导致优化不是很显著。第三次和第四次user_id不需要回表,所以优化很明显。
  2. 为什么第四次优化的第一次SQL和第二次执行SQL耗时这么慢?
    • 因为innodb_buffer_pool_size缓存么?

原文地址:http://blog.51cto.com/11819159/2092395

时间: 2024-10-12 22:59:05

【20180329】MySQL优化SQL一则以及思考的相关文章

mysql优化sql语句

mysql优化sql语句 常见误区 www.2cto.com 误区1: count(1)和count(primary_key) 优于 count(*) 很多人为了统计记录条数,就使用 count(1) 和 count(primary_key) 而不是 count(*) ,他们认为这样性能更好, 其实这是一个误区.对于有些场景,这样做可能性能会更差,应为数据库对 count(*) 计数操作做了一些特别的优化. 误区2: count(column) 和 count(*) 是一样的 这个误区甚至在很多

mysql优化SQL语句消耗

开启SQL的慢日志查询 配置文件文件中填写如下配置并重启mysql log_queries_not_using_indexes #这个参数设置为ON,可以捕获到所有未使用索引的SQL语句,尽管这个SQL语句有可能执行得挺快. log-bin=mysql-bin   slow_query_log=on     long_query_time=2     log_queries_not_using_indexes=on   slow-query-log-file=/var/lib/mysql/slo

30种mysql优化sql语句查询的方法

1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描. 3.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: select id from t where num is null 可以在num上设置默认值0,确保表中num列没有null值,然后这样查询: select id from

四,mysql优化——sql语句优化小技巧

1,大批量插入数据 (1)对于MyISAM: alter table table_name disable keys; loading data; alter table table_name enables keys; (2)对于Innodb: (a),将要导入的数据按照主键排序: (b),set unique_checks = 0,关闭唯一性校验: (c),set autocommit=0,关闭自动提交: 2,MyISAM与Innodb区别是什么 (1)MyISAM不支持外键,Innodb支

MySQL 优化sql explain执行计划详解

mysql explain执行计划详解 1).id列数字越大越先执行,如果说数字一样大,那么就从上往下依次执行,id列为null的就表是这是一个结果集,不需要使用它来进行查询. 2).select_type列常见的有:A:simple:表示不需要union操作或者不包含子查询的简单select查询.有连接查询时,外层的查询为simple,且只有一个B:primary:一个需要union操作或者含有子查询的select,位于最外层的单位查询的select_type即为primary.且只有一个C:

mysql 优化面试题

第一方面:30种mysql优化sql语句查询的方法 1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by涉及的列上建立索引. 2.应尽量避免在 where 子句中使用 !=或<> 操作符,否则将引擎放弃使用索引而进行全表扫描. 3.应尽量避免在 where 子句中对字段进行 null 值 判断,否则将导致引擎放弃使用索引而进行全表扫描,如: select id from t where num is null 可以在num上设置默认值0,确保表中num列没有n

对mysql的高并发优化配置的一些思考

对mysql的高并发优化配置的一些思考 mysql的高并发优化配置方案很多,但是适应你自己的就变得很少了,我们对数据库的优化,无非就是为了应对mysql的高并发情况罢了.随着大数据的时代的到来和网络用户的增多,很多企业中,可能每天应对的数量达百万,千万,甚至上亿的pv量,这样的量已经是超过普通配置的mysql所承受的量,所以应对日益增长的pv量,我们需要对mysql做出相应的对策,进一步优化mysql,达到我们所预期的效果,预防因为高并发所引起的mysql宕机,通过调试优化mysql,我们便可以

大牛是怎么思考设计MySQL优化方案的?

在进行MySQL的优化之前,必须要了解的就是MySQL的查询过程,很多查询优化工作实际上就是遵循一些原则,让MySQL的优化器能够按照预想的合理方式运行而已.图-MySQL查询过程 一.优化的哲学 注:优化有风险,涉足需谨慎 1.优化可能带来的问题 优化不总是对一个单纯的环境进行,还很可能是一个复杂的已投产的系统: 优化手段本来就有很大的风险,只不过你没能力意识到和预见到: 任何的技术可以解决一个问题,但必然存在带来一个问题的风险: 对于优化来说解决问题而带来的问题,控制在可接受的范围内才是有成

mysql优化-数据库优化、SQL优化

我有一张表w1000,里面有1000万条数据,这张表结构如下:CREATE TABLE `w1000` ( `id` varchar(36) NOT NULL, `name` varchar(10) DEFAULT NULL, `age` int(3) DEFAULT NULL, `money` double(8,2) DEFAULT NULL, `address` varchar(100) DEFAULT NULL, `create_date` datetime(3) DEFAULT NULL