公布MySQL数据库索引查询优化的分享

客户还是可以使用DBaaS系统所能提供的所有能力。数据库云服务消除了组织对专职人员、本地数据库存储设备的需要。他们不必安装、配置和维护任何软硬件。成绩形貌：
我们要会见的表是一个十分年夜的表，四万万笔记录，id是主键，PRogram_id上建了索引。
实行一条SQL:
select*fromprogram_access_logwhereprogram_idbetween1and4000
这条SQL十分慢。
我们原觉得处置纪录太多的缘故原由，以是加了id限定，一次只读五十万笔记录
select*fromprogram_access_logwhereidbetween1and500000andprogram_idbetween1and4000
可是这条SQL仍旧很慢，速率比下面一条几近没有提拔。
MySQL处置50万笔记录的表，前提字段还建了索引，这条语句应当是刹时完成的。
成绩剖析：
这张表约莫容量30G，数据库服务器内存16G，没法一次载进。就是这个形成了成绩。
这条SQL有两个前提，ID一到五十万和Program_id一到四千，由于program_id局限小很多，mysql选择它做为次要索引。
先经由过程索引文件找出了一切program_id在1到4000局限里一切的id，这个历程十分快。
接上去要经由过程这些id找出内外的纪录，因为这些id是团圆的，以是mysql对这个表的会见不是按次读取。
而这个表又十分年夜，没法一次装进内存，以是每会见一笔记录mysql都要从头在磁盘上定位并把四周的纪录都载进内存，大批的IO操纵招致了速率的下落。
成绩办理计划：
1.以program_id为前提对表举行分区
2.分表处置，每张表的巨细不凌驾内存的巨细
但是，服务器用的是mysql5.0，不撑持分区，并且这个表是大众表，没法在不影响别的项目标前提下修正表的布局。
以是我们接纳了第三种举措：
select*fromprogram_access_logwhereidbetween1and500000andprogram_idbetween1and15000000
如今program_id的局限宏大于id的局限，id被当作次要索引举行查找，因为id是主键，以是查找的是一连50万笔记录，速率和会见一个50万笔记录的表基础一样
总结：
这是一个在万万条记录表中因为利用了索引诱致了数据查找变慢的成绩，有必定的典范性和人人交换下！
对于IT经理来说，令他们喜欢的MySQL的简单性还有另一方面。MySQL可以运行的更快速。某些人或许会说MySQL缺少了一些人们想要的功能。

这一点很好的加强了profiler的功能。但是提到profiler提醒大家注意一点。windows2003要安装sp1补丁才能启动profiler。否则点击没有反应。

仓酷云

同样会为索引视图等应用带来麻烦。看看行级和事务级的快照数据放在tempdb中，就能感觉到目前架构的尴尬。

需要注意的一点，也是我使用过程中发现的一个问题。在建立function->schema->table后，如果在现有的分区表上建立没有显式声明的聚集索引时，分区表会自动变为非分区表。这一点很让我纳闷。

入门没那么困难，精通没那么容易

再开发调试阶段和OLAP环境中，外键是可以建立的。新版本中加入了SETNULL和SETDEFAULT属性，能够提供能好的级联设置。

groupby子句可以将查询结果分组，并返回行的汇总信息Oracle按照groupby子句中指定的表达式的值分组查询结果。

呵呵，这就是偶想说的