时间：2021-07-01 10:21:17 帮助过：47人阅读
好久没有写点东西了， 与其说是忙不如说是太懒。 先问个问题：[48,281,1,56,99,6]和[1,6,18,45,56,99,281]是两个完全一样的数组，前者是无规律可言的，后者是已经排好序的，要想把每个数组里边大于100的数找出来或者排序 那一个更快一些？ 不用我说，地球人
好久没有写点东西了， 与其说是忙不如说是太懒。
先问个问题： [48,281,1,56,99,6] 和 [1,6,18,45,56,99,281] 是两个完全一样的数组，前者是无规律可言的，后者是已经排好序的，要想把每个数组里边大于100的数找出来或者排序 那一个更快一些？ 不用我说，地球人除了傻子都知道是后者。索引就是数据表按照某一个字段或者几个字段做出排序的数据结构。
因为已经存了这些字段的排列顺序，我们就可以理解为这些数据是按照某些字段排好序的，这样取数据的时候速度就会快乐好多倍， 当数据量较少的时候索引的优势体现的并不明显， 当数据量非常大的时候，你就会发现有没有索引数据库的性能会是天壤之别。
但是索引有几个误区：
1. 索引越多越好。
好多人都说这个是错的，我看未必全错！要根据实际情况来，如果你的数据库是读写分开，在Master上写数据，在Slave上读数据， 完全可以单独在Slave上多创建几个索引 。
别的地方的解释是索引会影响数据写入的性能，还有索引多了会占用更多的硬盘空间。要想数据按照某一个或者多个字段有序地排列，系统会保存一个索引文件，多占一些硬盘空间是难免的， 另外插入记录和修改记录的时候要重新计算该记录的排序位置，并更新索引文件， 所以让insert和update 操作变慢也是肯定的。
这种想法基本上已经过时了，现在大多数的应用，尤其是数据量大到让你不得不去看一些索引优化的时候，我个人觉得你的数据库该考虑采用replication架构了，采用replication 架构的话一种提高性能非常主流又非常有效，那就是读服务器和写服务器分开。 Replication架构很好的一点就是， master 与 slave的结构可以不一样，可以采用不同的存储引擎，可以建不同的索引，他们是通过binlog来进行数据同步的， 但是主从数据库不一致是有底线的， 你必须要保证你的程序生成的sql语句在master和slave上是都可以执行的而且效果一样。 这样的话插入在master上， 我们不建索引， 读取在从服务器上我们可以多建一些索引，对数据库的插入影响还是不大的。 另外现在还计较这些硬盘空间的人完全就是扯淡！！ 硬盘太便宜了，只要性能上的去， 流量上的去 还在乎这点空间吗?
2. 索引建在要查询的字段上
哥可以很负责任地告诉你， 这绝对是错的！！ 我们可以分解查询操作，没有索引的时候，系统是这样执行你的 select col1, col2 from table where col3=xxxx ：
系统先去查数据表table， 然后一条一条地计算 where 子句的东西 col3=xxx是否为true, 是true的话就取。索引的用途是不用再一条一条遍历了,你要查询的列已经基本有序， 采用二分法直接去查找就行了。效率节约到这里了， 跟你要查询的列屁关系没有。
当索引出现在 where 子句中有几点要注意：
1. where sin(column) > 0.5 , 当索引列作为函数参数的时候， 系统不会采用索引， 解决的办法就是换算一下，尽量不要索引列作为参数
2. where column like '%xxxx' ， 通配符出现在左边的时候， 系统不会使用索引
（未完待续，待润色）
声明: 本文采用 CC BY-NC-SA 3.0 协议进行授权
转载请注明来源：小景的博客
本文链接地址：http://www.phpv5.com/blog/archives/374/