mysql索引设计原则

标签：blog   必须   速度   prim   修改表   建议   结构   图片   磁盘空间   

索引设计原则

• 选择唯?一性索引
  • 唯?一性索引的值是唯?一的，可以更更快速的通过该索引来确定某条记录
• 为常作为查询条件的字段建?立索引
  • 如果某个字段经常?用来做查询条件，那么该字段的查询速度会影响整个表的查询速度。因
    此，为这样的字段建?立索引，可以提?高整个表的查询速度
• 限制索引的数?目
  • 索引的数?目不不是越多越好
  • 每个索引都需要占?用磁盘空间，索引越多，需要的磁盘空间就越?大
  • 修改表时，对索引的重构和更更新很麻烦
  • 越多的索引，会使更更新表变得很浪费时间
• 尽量量使?用数据量量少的索引
  • 如果索引的值很?长，那么查询的速度会受到影响
    • 例如：对?一个char(100)类型的字段进?行行全?文检索需要的时间肯定?比对char(10)类型的字
      段需要的时间更更多
• 为经常需要排序、分组和联合操作的字段建?立索引
  • 经常需要order by、group by、distinct和union等操作的字段，排序操作会浪费很多时间。
    如果为其建?立索引，可以有效的避免排序操作
• 尽量量使?用前缀索引
  • 如果索引字段的值很?长，最好使?用值的前缀来索引
    • 例如：text和blog类型的字段，进?行行全?文检索会浪费时间。如果只检索字段的前?面的若
      干个字符，这样可以提?高检索速度
• 删除不再使?用或者很少使?用的索引
  • 表中数据被?大量量更更新，或者数据的使?用?方式被改变后，原有的?一些索引可能不不再需要。数据
    库管理理员应当定期找出这些索引，将他们删除，从?而减少索引对更更新操作的影响
• 小表不不应建议索引(超过200w数据的表，建?立索引)
  包含?大量量的列列并且不不需要搜索?非空值的时候可以考虑不不建索引
• 经常被?用来过滤记录的字段
  primary key 字段，系统?自动创建主键的索引
  unique key 字段，系统?自动创建对应的索引
  foreign key 约束所定义的作为外键的字段
  在查询中?用来连接表的字段
  经常?用来作为排序(order by的字段)基准的字段
  索引会占?用磁盘空间，创建不不必要的索引只会形成浪费
  索引的创建必须考虑数据的操作?方式
  内容很少变动，经常被查询，为它多创建?几个索引?无所谓
  经常性，例例?行行性变动的表?而?言，则需要谨慎地创建确实必要的索引
  复合索引和单?一索引
  复合索引是指多字段联合索引，查询时经常需要这?几个字段组合?一起为条件再查询
  唯?一索引主要是?用主键ID索引，存储的结构顺序与物流结构?一直
  添加和删除索引的情况
  表的主键、外键必须有索引
  数据量量超过300w的表应该有索引
  经常与其他表进?行行连接的表，在连接字段上应该建?立索引
  经常出现在where?子句句中的字段，特别是?大表的字段，应该建?立索引；
  索引应该建?立选择性?高的字段上；
  索引应该建在?小字段上，对于?大的?文本字段甚?至超?长字段，不不要建索引；
  复合索引的建?立需要进?行行仔细分析；尽量量考虑?用单字段索引代替：
  正确选择复合索引中主列列字段，?一般是选择性较好的字段
  复合索引的?几个字段是否经常同时以AND?方式出现在where?子句句中？单字段查询是否极
  少甚?至没有？
  如果是，则可以建?立复合索引；否则考虑单字段索引；
  如果复合索引中包含的字段经常单独出现在where?子句句中，则分解为多个单字段索
  引？
  如果复合索引所包含的字段超过3个，那么仔细考虑其必要性，考虑减少复合的字
  段；
  如果既有单字段索引，?又有这?几个字段是哪个的复合索引，?一般可以删除复合索
  引；
  频繁进?行行数据操作的表，不不要建?立太多的索引
  删除?无?用的索引，避免对执?行行计划造成负?面影响

mysql索引设计原则

标签：blog   必须   速度   prim   修改表   建议   结构   图片   磁盘空间   

原文地址：https://www.cnblogs.com/oklizz/p/12076519.html