MySQL开发实践8问，你能hold住几个？

| 1 | 0.00024700 | select * from mytable where id=100 |

| 2 | 0.27912900 | select * from mytable where id+1=101 |

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

别的很多同窗在拉取全表数据时，爱好用select xx from xx limit 5000,1000这种情势批量拉取，其拭魅这个SQL每次都是全表扫描，建议添加1个自增id做索引，将SQL改为select xx from xx where id>5000 and id;

+----------+------------+-----------------------------------------------------+ 
 
| Query_ID | Duration | Query | 
 
+----------+------------+-----------------------------------------------------+ 
 
| 1 | 0.00415400 | select * from mytable where id>=90000 and id91000 | 
 
| 2 | 0.10078100 | select * from mytable limit 90000,1000 | 
 
+----------+------------+-----------------------------------------------------+

合理用好索引，应当可解决大年夜部分SQL问题。当然索引也非越多越好，过多的索引会影响写操作机能

只select出须要的字段，避免select

+----------+------------+-----------------------------------------------------+ 
 
| Query_ID | Duration | Query | 
 
+----------+------------+-----------------------------------------------------+ 
 
| 1 | 0.02948800 | select count(1) from ( select id from mytable ) a | 
 
| 2 | 1.34369100 | select count(1) from ( select * from mytable ) a | 
 
+----------+------------+-----------------------------------------------------+

尽量早做过滤，使Join或者Union等后续操作的数据量尽量小

把能在逻辑层算的提到逻辑层来处理，如一些数据排序、时光函数计算等

…….

PS：关于SQL优化，已经有足够多文┞仿了，所以就不讲太周全了，只重点说本身1个感触感染：索引!根本都是因为索引!

4.SQL层面已难以优化，请求量持续增大年夜时的应对策略?

下面是我能想到的几个办法，每个办法又都是一篇大年夜文┞仿了，这里就不展开

分库分表

MySQL> explain select * from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) > 123456789; 
 	
			 4/6   首页 上一页 2 3 4 5 6 下一页 尾页	
			

　　推荐阅读
　　更好的指标、更好的云优先策略
            
            对于具有大年夜型复杂IT情况的CIO来说，云优先策略的风险和收益是一个难题。专家建议要应用明显的指标。TCE Strategy首席履行官、技巧和收集安然策略师Bryce  Austin表示：“在这种情>>>详细阅读


本文标题：MySQL开发实践8问，你能hold住几个？
地址：http://www.17bianji.com/lsqh/37266.html
 1/2    1