原文链接：http://www.mysqlops.com/2011/05/23/mysql%E4%B8%AD%E5%88%9B%E5%BB%BA%E5%8F%8A%E4%BC%98%E5%8C%96%E7%B4%A2%E5%BC%95%E7%BB%84%E7%BB%87%E7%BB%93%E6%9E%84%E7%9A%84%E6%80%9D%E8%B7%AF.html

【导读】
通过一个实际生产环境中的数据存取需求，分析如何设计此存储结构，如何操纵存储的数据，以及如何使操作的成本或代价更低，系统开销最小。同时，让更多初学者明白数据存储的表上索引是如何一个思路组织起来的，希望起到一个参考模板的价值作用。

测试用例描述
测试用例为B2C领域，一张用于存储用户选购物品而生成的产品订单信息表，不过去掉一些其他字段，以便用于测试，其表中的数据项也不特别描述，字段意思见表

USE `test`;
DROP TABLE IF EXISTS `test`.`goods_order`;
CREATE TABLE `goods_order`(
`order_id`        INT UNSIGNED      NOT NULL             COMMENT ‘订单单号’,
`goods_id`        INT UNSIGNED      NOT NULL DEFAULT ’0′ COMMENT ‘商品款号’,
`order_type`      TINYINT UNSIGNED  NOT NULL DEFAULT ’0′ COMMENT ‘订单类型’,
`order_status`    TINYINT UNSIGNED  NOT NULL DEFAULT ’0′ COMMENT ‘订单状态’,
`color_id`        SMALLINT  UNSIGNED NOT NULL DEFAULT ’0′ COMMENT ‘颜色id’,
`size_id`         SMALLINT  UNSIGNED NOT NULL DEFAULT ’0′ COMMENT ‘尺寸id’,
`goods_number`    MEDIUMINT  UNSIGNED NOT NULL DEFAULT ’0′ COMMENT ‘数量’,
`depot_id`        INT UNSIGNED  NOT NULL DEFAULT ’0′ COMMENT ‘仓库id’,
`packet_id`       INT UNSIGNED  NOT NULL DEFAULT ’0′ COMMENT ‘储位code’,
`gmt_create`      TIMESTAMP     NOT NULL DEFAULT ’0000-00-00 00:00:00′ COMMENT ‘添加时间’,
`gmt_modify`      TIMESTAMP     NOT NULL DEFAULT ’0000-00-00 00:00:00′ COMMENT ‘更新时间’,
PRIMARY KEY(order_id,`goods_id`)
)ENGINE=InnoDB AUTO_INCREMENT=1 CHARACTER SET ‘utf8′ COLLATE ‘utf8_general_ci’;

其中，主键信息：PRIMARY KEY(order_id,`goods_id`)，为何主键索引索引字段的顺序为：order_id,`goods_id`，而不是： `goods_id`, order_id呢？原因很简单，goods_id在订单信息表中的重复率会比order_id高，也即order_id的筛选率更高，可以减少扫描索引记录个数，从而达到更高的效率，同时，下面即将会列出的SQL也告诉我们，有部分SQL语句的WHERE字句中只出现order_id字段，为此更加坚定我们必须把字段：order_id作为联合主键索引的头部，`goods_id`为联合主键索引的尾部。

数据存储表设计的小结：
设计用于存储数据的表结构，首先要知道有哪些数据项，也即行内常说的数据流，以及各个数据项的属性，比如存储的数据类型、值域范围及长度、数据完整性等要求，从而确定数据项的属性定义。存储的数据项信息确定之后，至少进行如下三步分析：
l 首先，确定哪些数据项或组合，可以作为记录的唯一性标志；
l 其次，要确定对数据记录有哪些操作，每个操作的频率如何，对网站等类型应用，还需要区分前台操作和后台操作，也即分外部用户的操作，还是内部用户的操作；
l 最后，对作为数据记录操作的条件部分的数据项，分析其数据项的筛选率如何，也即数据项不同值占总数据记录数的比例关心，比例越接近1则是筛选率越好，以及各个值得分布率；
综上所述，再让数据修改性操作优先级别高于只读性操作，就可以创建一个满足要求且性能较好的索引组织结构。
数据的存取设计,就涉及一块非常重要的知识: 关系数据库的基础知识和关系数据理论的范式。对于范式的知识点，特别解释下，建议学到BCNF范式为止，1NF、2NF、3NF和BCNF之间的差别，各自规避的问题、存在的缺陷都要一清二楚，但是在真实的工作环境中，不要任何存取设计都想向范式靠，用一句佛语准确点表达：空即是色，色即是空。

用于生成测试数据的存储过程代码
创建索引，就离不开表存储的真实数据，为此编写一个存储过程近可能模拟真实生产环境中的数据，同时也方便大家使用此存储过程，在自己的测试环境中，真实感受验证，
存储过程代码：

DELIMITER $$
DROP PROCEDURE IF EXISTS `usp_make_data` $$
CREATE PROCEDURE `usp_make_data`()
BEGIN
DECLARE iv_goods_id INT UNSIGNED DEFAULT 0;
DECLARE iv_depot_id INT UNSIGNED DEFAULT 0;
DECLARE iv_packet_id INT UNSIGNED DEFAULT 0;
 
SET iv_goods_id=5000;
SET iv_depot_id=10;
SET iv_packet_id=20;
 
WHILE iv_goods_id>0
DO
START  TRANSACTION;
WHILE iv_depot_id>0
DO
WHILE iv_packet_id>0
DO
INSERT INTO goods_order(order_id,goods_id,order_type,order_status,color_id,size_id,goods_number,depot_id,packet_id,gmt_create,gmt_modify)
VALUES(SUBSTRING(RAND(),3,8),iv_goods_id,SUBSTRING(RAND(),3,1),SUBSTRING(RAND(),5,1)%2,SUBSTRING(RAND(),3,3),SUBSTRING(RAND(),4,3),SUBSTRING(RAND(),5,2),
iv_depot_id,SUBSTRING(RAND(),4,2)*iv_packet_id,DATE_ADD(NOW(),INTERVAL -SUBSTRING(RAND(),2,3) DAY),DATE_ADD(NOW(),INTERVAL -SUBSTRING(RAND(),3,2) DAY)
);
SET iv_packet_id=iv_packet_id-1;
END WHILE;
SET iv_packet_id=20;
SET iv_depot_id=iv_depot_id-1;
END WHILE ;
 
COMMIT;
SET iv_depot_id=10;
SET iv_goods_id=iv_goods_id-1;
END WHILE ;
END $$
DELIMITER ;

业务逻辑描述
l 非注册用户，或网站的注册用户不登陆，都能可选购买物品，生成订单号对应的用户UID为系统默认的；
l 订单与用户UID关联、描述等信息，存储其它的表中，通过订单号的模式关联；
l 用户的订单信息，在未付款之前都可以再修改，付款之后则无法修改；
l 已经付费的订单信息，自动发送到物流部门，进行后续工序的操作。处理完毕之后，会更新订单中涉及物品的存储位置信息；
l 定期读取部分数据到数据仓库分析系统，用于统计分析；
l 个人订单查询，前后台都有；
l 购物记录查询显示；

根据业务规则描述需要使用操纵数据的SQL语句
(1). EXPLAIN SELECT * FROM goods_order WHERE `order_id`=40918986;
(2). SELECT * FROM goods_order WHERE `order_id` IN (40918986,40717328,30923040…) ORDER BY gmt_modify DESC;
(3). UPDATE goods_order SET gmt_modify=NOW(),…. WHERE `order_id`=40717328 AND goods_id=4248;
(4). SELECT COUNT(*) FROM goods_order WHERE depot_id=0 ORDER BY gmt_modify DESC LIMIT 0,50;
(5). SELECT * FROM goods_order WHERE depot_id=6 AND packet_id=0 ORDER BY gmt_modify DESC LIMIT 0,50;
(6). SELECT COUNT(*) FROM goods_order WHERE goods_id=4248 AND order_status=0 AND order_type=1
(7). SELECT * FROM goods_order WHERE goods_id=4248 AND order_status=0 AND order_type=1 ORDER BY gmt_modify DESC LIMIT 0,50;
(8). SELECT * FROM goods_order WHERE gmt_modify>=’ 2011-04-06’;
8条SQL语句按触发其执行的用户分类：
l 前台用户点击触发的操作而会执行的SQL语句为：(1)、(2)、(3)；
l 后台内部用户点击触发的操作而会执行的SQL语句为：(1)、(2)、(3)、(4)、(5)、(6)、(7)；
l 后台系统自动定期执行：(4)、(5)、(6)、(7)，工作时间正常情况每隔15分钟执行一次，以检查是否有已付款而没有准备货物的订单、是否有收款而未发货的订单等;
l 统计分析系统定期导出数据而执行的SQL语句为：(8)，频率为每24小时一次；
我们再分析上述列出来的SQL，分为2类，一类是读操作的SQL（备注：SELECT操作），另外一类为修改性操作（备注：UPDATE、DELETE操作），分别如下：
SELECT 的WHERE子句、GROUP BY子、ORDER BY 子句和HAVING 子句中，出现的字段：
(1). order_id
(2). order_id+gmt_modify
(3). depot_id+gmt_modify
(4). depot_id+packet_id+gmt_modify
(5). goods_id+order_status+order_type
(6). goods_id+order_status+order_type+gmt_modify
(7). gmt_modify
修改性操作的WHERE子句中出现的条件字段：
(8). order_id+ goods_id

我们已经存在主键索引：PRIMARY KEY(order_id,`goods_id`)，另外考虑到此表数据的操作以SELECT和INSERT为主，UPDATE的SQL量其次，再根据上述SQL语句，为此我们可以初步确定需要创建的索引：
ALTER TABLE goods_order
ADD INDEX idx_goodsID_orderType_orderStatus_gmtmodify(goods_id,order_type,order_status,gmt_modify),
ADD INDEX idx_depotID_packetID_gmtmodify(depot_id,packet_id,gmt_modify);

总结：
文章中也分析了为何联合主键索引的顺序为：order_id,`goods_id`，再补充下作为主键的联合索引的字段属性的其他特性：字段值写入之后不变化、字段值长度短且最好为数值类型；
对于编号SQL：(8)，每天按更新日期读取一次数据的操作，以采用全表扫描的方式实现，牺牲其数据读取的性能，以减少更新字段修改日期的值而带来的索引维护开销；
对于编号SQL：(4)、(5)，考虑到每次都是读取最新的５０条记录，以及读取的数据基本上可肯定为热数据，为此不得不牺牲其中一条SQL的数据读取性能，而少创建一个联合索引，从而减少维护索引字段的IO量；
对于编号SQL：(6)、(7)，创建的联合索引，需要特别注意联合索引：idx_goodsID_orderType_orderStatus_gmtmodify(goods_id,order_type,order_status,gmt_modify)中的字段顺序，其中：
l goods_id字段的筛选率高于order_type,order_status，另外gmt_modify字段只出现在ORDER BY子句中，为此只有让goods_id字段作为联合索引的头部，以提高索引的筛选率，从而提高索引的效率，减少逻辑或物理的读。
l order_status字段只有0或1两种值，而order_type有多种，以及根据SQL语句，必须order_type出现在联合中的位置要比order_status靠近头部；
l gmt_modify字段出现在ORDER BY子句中，为此必须放到联合索引字段的最后；

最后，再梳理一下从需求到设计存储结构，再到编写SQL和创建索引结构，我们应该做的步骤：
l 整理业务产生的数据流，读取数据的方式；
l 整理清楚数据流中的每个数据项属性信息；
l 分析业务指标，推测需要存储数据的规模（备注：一定要以多少GB作为容量单位）；
l 选择可能用于支持业务的硬件设备和数据库架构；
l 把所有可能操纵数据的条件和操作类型，都整理清楚；
l 分析操纵数据条件字段各自的数据筛选率；
l 权衡各个SQL的性能和IO量，也即类似于哪个操作权重高一些，那些操作权重适当低一些；
l 创建索引组织结构；
l 收集测试和生产环境的反馈信息，优化索引组织结构；

备注：
本想再用测试环境结合业务的方式，跑一套模拟测试脚本程序，让大家更加直观地看到不同索引组织情况下，相同的SQL操作及频率，数据库服务器的处理能力和负载变化及对比信息，可惜唯一的服务器无法使用了，只好放弃。对于分析相同的SQL，走不通索引，其需要的逻辑IO和物理IO量也是一个办法，此次就不分析了，有需要的朋友可以去玩玩，另外建议初学者一定要好好阅读下mysql 手册上的相关章节内容：7.2.6. Index Merge Optimization。

类似的文章

• 2010年03月20日 -- MySQL索引与存储方式对性能的影响 (2)
• 2009年12月21日 -- 给MySQL做虚拟的“函数索引” (0)
• 2009年11月10日 -- MySQL索引检查脚本预览 (0)

本文配图来自《高性能MySQL(第二版)》。

在数据库中，对性能影响最大的几个策略包括数据库的锁策略、缓存策略、索引策略、存储策略、执行计划优化策略。
索引策略决定数据库快速定位数据的效率，存储策略决定数据持久化的效率。
MySQL中两大主要存储引擎MyISAM和InnoDB采用了不同的索引和存储策略，本文将分析它们的异同和性能。

MySQL主要提供2种方式的索引：B-Tree（包括B+Tree）索引，Hash索引。
B树索引具有范围查找和前缀查找的能力，对于N节点的B树，检索一条记录的复杂度为O(LogN)。
哈希索引只能做等于查找，但是无论多大的Hash表，查找复杂度都是O(1)。
显然，如果值的差异性大，并且以等于查找为主，Hash索引是更高效的选择，它有O(1)的查找复杂度。如果值的差异性相对较差，并且以范围查找为主，B树是更好的选择，它支持范围查找。

Hash索引各种引擎大同小异，没有太多可探讨性，本文主要讨论不同形式的B树索引。

B树属于二叉平衡树，平衡树就是任何一个节点的左右节点高度差距不能超过1的树，这才是绝对平衡的树。
平衡树比较好的算法是AVL，它通过左旋、右旋及其组合的操作可以保证树绝对平衡。
下面是AVL算法中的全部旋转操作：

平衡树处在任何一个左边的不平衡状态都可以通过相应的旋转操作转移到右边的平衡状态。

数据库采用的B树只在叶子节点记录信息，非叶子节点记录的是范围信息，这是与一般搜索树不同的地方（一般搜索树非叶子节点也记录信息）。
这是一个B+树的结构，InnoDB的索引都采取了这种形式，它在B-树的基础上为每个叶子节点加了一个指针指向下一个叶子节点，这样可以快速的进行范围查找。
MyISAM是否也是B+树我还不能确定，但是B-树我没有想到可以快速进行范围查找的方法，应该也是B+树。

例如这个B+树的例子：

如果我要查找名字以A开头的全部信息，我只要获取第一个叶子节点，然后顺序沿着指向下一个叶子的指针，直到发现当年叶子节点已经不是以A开头则中止，这样只要搜索到第一个叶子节点(O(LogN))再沿着指针检索(O(N))，就可以获取全部索引，如果N个节点的表扫描M个连续值，就是O(LogN)+O(M)，如果B-树则需要回溯到上层节点，这样最差的效率是O(LogN)*M。

对于InnoDB，使用了一种改进的B+树索引，称为聚集索引（Clustered Index），它的不同之处在于索引上不仅有索引值的信息，还有整个索引值所在行的信息，免去了一次通过索引值上的位置去取整行的操作。

假设我们有个表有(col1,col2)列，col1是主键，col2也建立索引。那么在MyISAM引擎中，文件会被这样记录，因为MyISAM是按插入顺序把数据写入文件。如果有删除则空出位置，再次插入如果可以放下则会填充空白，对于不定长的行，存储引擎都会在分页中预留位置，以供更新更长的值（一般是VARCHAR），放不下则会添加到文件结尾，并从原位置删除。所以有时候会有空间浪费，需要Optimize Table来优化。
因此：定长的行比不定长的行效率高！把定长数据和不定长数据分开存储，很多时候可以提高效率。

再来看MyISAM的主键索引，索引Key是主键值，索引Value是行的文件位置，通过这个位置可以直接读取行。从这个图上来看，MyISAM也是采用B+树。

MyISAM的非主键索引，跟逐渐索引没有不同，也是索引行的文件位置。

再看InnoDB的主键索引，索引Key是主键值，索引Value是整行的数据。

InnoDB的非主键索引，索引Key是列值，索引Value是主键值。

对比MyISAM和InnoDB的索引策略：

可以发现MyISAM所有列的索引都是一样，索引Key是列值，索引Value是行的文件位置。
InnoDB的主键索引包含了行的全部信息，索引Key是主键值，索引Value是整行的值。而非主键索引索引Key是列值，索引Value是主键值，取数据时到主键索引中取。

并且在InnoDB中，一个聚集索引是必须的，如果没有定义主键，InnoDB也会自己隐含的建立一个聚集索引作为主键，因为InnoDB的主键索引还有个重要的功能就是行锁，这在我的另一篇文章中分析过。

再来看看我们插入值时会发生什么：

InnoDB会按主键索引顺序组织文件，如果按主键顺序插入，可以直接在最尾部加入。并且只填充页面的15/16，这样可以预留部分空间以供行修改，这样组织的数据是非常紧凑的。

如果主键不是顺序的，我们来看看会发生什么，因为要按主键顺序存放，数据会被不断地移动，调整页面。

所以：InnoDB引擎按主键顺序插入记录是非常必要的，否则性能将会面临很大风险。

类似的文章

• 2009年09月30日 -- MySQL参数调优 (0)
• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)
• 2011年12月23日 -- 在Server层实现Kill Idle Transaction (1)

荣耀属于：Tomas Zhang

逻辑上：

• Single column 单行索引
• Concatenated 多行索引
• Unique 唯一索引
• NonUnique 非唯一索引
• Function-based函数索引
• Domain 域索引

物理上：

• Partitioned 分区索引
• NonPartitioned 非分区索引
• B-tree：
  • Normal 正常型B树
  • Rever Key 反转型B树
  • Bitmap 位图索引

索引结构：

• B-tree：
  • 适合与大量的增、删、改（OLTP）；
  • 不能用包含OR操作符的查询；
  • 适合高基数的列（唯一值多）；
  • 典型的树状结构；
  • 每个结点都是数据块；
  • 大多都是物理上一层、两层或三层不定，逻辑上三层；
  • 叶子块数据是排序的，从左向右递增；
  • 在分支块和根块中放的是索引的范围；
• Bitmap：
  • 适合与决策支持系统；
  • 做UPDATE代价非常高；
  • 非常适合OR操作符的查询；
  • 基数比较少的时候才能建位图索引；

树型结构：

• 索引头：
  • 开始ROWID，结束ROWID（先列出索引的最大范围）；
• BITMAP：
  • 每一个BIT对应着一个ROWID，它的值是1还是0，如果是1，表示着BIT对应的ROWID有值；

类似的文章

• 2011年06月2日 -- MySQL中创建及优化索引组织结构的思路 (0)
• 2010年03月20日 -- MySQL索引与存储方式对性能的影响 (2)
• 2010年01月9日 -- 在OEL5.4上安装Oracle 10g R2 x64 RAC的一些记录 (1)

对于带有列的函数计算的SQL，MySQL是无法使用索引的，MySQL并没有Oracle中的函数索引，
例如：

SELECT *
FROM table_1
WHERE func_1(col_1) < const_1
AND  func_2(col_2) = const_2
ORDER BY func_1(col_1);

在Oracle中，我们可以建里组合函数索引：

CREATE INDEX idx_1 ON table_1 ( func_2(col_2), func_1(col_1));

但是在MySQL中，没有提供函数索引，怎么办？就此罢休？存在这样的需求，就得去解决，遂想到使用冗余+触发器来虚拟函数索引。
首先，利用新列来存储函数计算的结果，增加col_1_f1，col_2_f2两个列分别存储col_1/col_2的函数计算结果，然后写2个触发器，分别处理INSERT和UPDATE的情况。

CREATE TRIGGER trg_f1 BEFORE UPDATE
ON verycd  FOR EACH ROW
BEGIN
    SET NEW.col_1_f1=func_1(NEW.col_1);
    SET NEW.col_2_f2=func_2(NEW.col_2);
END;
 
CREATE TRIGGER trg_f1 BEFORE INSERT
ON verycd  FOR EACH ROW
BEGIN
    SET NEW.col_1_f1=func_1(NEW.col_1);
    SET NEW.col_2_f2=func_2(NEW.col_2);
END;

然后我们对col_1_f1，col_2_f2两个列建索引：

CREATE INDEX idx_1 ON table_1 ( col_2_f2，col_1_f1 );

将查询语句改为：

SELECT *
FROM table_1
WHERE col_1_f1 < const_1
AND  col_2_f2 = const_2
ORDER BY col_1_f1;

这就实现了虚拟的“函数索引”，从这样看函数索引的实现并不复杂，MySQL只要在B-Tree中记录函数计算后的结果作为建树关键字就能实现，不知道MySQL为什么不做呢？
欢迎拍砖~

类似的文章

• 2011年06月2日 -- MySQL中创建及优化索引组织结构的思路 (0)
• 2010年03月20日 -- MySQL索引与存储方式对性能的影响 (2)
• 2009年11月10日 -- MySQL索引检查脚本预览 (0)

工作比较忙，还没整太多，暂时还没有把各个分析模块整合起来。
支持分析远程数据库索引，主要根据唯一性和业务中的使用情况进行分析，全功能使用需要general日志或者慢查日志，最好是General日志这样会考虑进表被修改的影响，分析结果要准确一些。
分析结果如下方式输出，包括表中一共包含的记录条数，可能没用的索引，以及无用索引的条数等。
鉴于目前分析结果还不能自动化，需要人工判断，只是帮我提高了一些效率，暂不放出代码，等能胜任生产环境我再放出代码。

|—————————————————–
|Table backpack_hotel Have 9 Index :
| Have 362 Rows!
|
|backpack_hotel stars 10
|backpack_hotel cat_id 6
|backpack_hotel cat_id_2 6
|backpack_hotel hotel_type 2
|backpack_hotel type 3
|
|[Have 5 Unused, 55.5555555555556 % of All!]
|—————————————————–

|—————————————————–
|Table backpack_hotel_additional Have 1 Index :
| Have 6 Rows!
|
|backpack_hotel_additional type 1
|
|[Have 1 Unused, 0 % of All!]
|—————————————————–

|—————————————————–
|Table backpack_hotel_cat Have 2 Index :
| Have 123 Rows!
|
|backpack_hotel_cat type 1
|
|[Have 1 Unused, 50 % of All!]
|—————————————————–

|—————————————————–
|Table backpack_hotel_cat_relate Have 3 Index :
| Have 283 Rows!
|
|
|[Have 0 Unused, 0 % of All!]
|—————————————————–

类似的文章

• 2011年06月2日 -- MySQL中创建及优化索引组织结构的思路 (0)
• 2010年03月20日 -- MySQL索引与存储方式对性能的影响 (2)
• 2009年12月21日 -- 给MySQL做虚拟的“函数索引” (0)