标签：rop 建议 col 表示 .com 一个 uniq 主机 崩溃恢复
创建并使用正确的索引【减少数据访问】
优点：加快检索速度、唯一索引保证每条数据唯一性等等，对生产系统的性能有质的提升；
缺点：索引会大大增加表记录的DML开销；
拓展：索引对DML(INSERT,UPDATE,DELETE)附加的开销有多少？
这个没有固定的比例，与每个表记录的大小及索引字段大小密切相关，以下是一个普通表测试数据，仅供参考：
索引对于Insert性能降低56%
索引对于Update性能降低47%
索引对于Delete性能降低29%
因此对于写IO压力比较大的系统，表的索引需要仔细评估必要性，另外索引也会占用一定的存储空间。
正确的索引可以让性能提升100，1000倍以上，不合理的索引也可能会让性能下降100倍，因此在一个表中创建什么样的索引需要平衡各种业务需求。
主键索引(聚集索引)、唯一索引、普通索引、组合索引、全文索引
例子：
ALTER TABLE `test_a` ADD INDEX `primary_key` (`id` ASC);
例子：
create unique index name_season_unique on test_a(name, season);
或者：
ALTER TABLE `test_a` ADD UNIQUE INDEX `name_season_unique` (`name` ASC, `season` ASC);
常用于
1、搜索时经常使用到的字段
2、用于连接其它表的字段
3、用于外键字段
4、高选中性的字段
5、order by子句中使用到的字段
6、xml类型
不适用于：
唯一性太差的字段不适合单独创建索引，即使频繁作为查询条件，例如性别
更新非常频繁的字段不适合创建索引，例如登录次数，最后登录时间
不会出现在 where 子句中的字段不该创建索引
例子：
create index name_index on test_a(name);
或者：
ALTER TABLE `test_a` ADD INDEX `name_index` (`name` ASC);
类似于普通索引，只是索引是放在多个列名上，例如字典表中部首+笔画的组合索引
create index name_no_index on test_a(name, season);
create fulltext index name_fulltext_index on test_a(name); -- 创建用于展示效果的数据 INSERT INTO `test_a` (`id`, `name`, `season`) VALUES (‘6‘, ‘不知水果‘, ‘不知季度‘); -- 展示效果 select match(name) against(‘不知水果‘) from test_a where id in(1, 6); drop index name_fulltext_index on test_a;
0表示没有匹配到，或者你的词是停止词，是不会建立索引的.
使用全文索引，不能使用like语句，如果使用like这样就不会使用到全文索引了
在建表的时候建立唯一键、普通索引、唯一索引的方式如下：
PRIMARY KEY (`id`), UNIQUE KEY `name_season_unique` (`name`,`season`), KEY `name_index` (`name`)
拓展：
删除索引
DROP INDEX index_name ON table_name;
或者：
ALTER TABLE `table_name` DROP INDEX `index_name`;
查看索引：
show index from table_name;
修改索引
我们一般是先删除再重新创建，也可以直接进行修改
查询要建立索引最重要的条件是查询条件中需要使用索引。
SQL什么条件会使用索引？
当字段上建有索引时，通常以下情况会使用索引：
INDEX_COLUMN = ?
INDEX_COLUMN > ?
INDEX_COLUMN >= ?
INDEX_COLUMN < ?
INDEX_COLUMN <= ?
INDEX_COLUMN between ? and ?
INDEX_COLUMN in (?,?,...,?)
INDEX_COLUMN like ?||‘%‘（后导模糊查询）
T1. INDEX_COLUMN=T2. COLUMN1（两个表通过索引字段关联）
SQL什么条件建了索引但不会使用索引？
|
查询条件 |
不能使用索引原因 |
示例 |
|
INDEX_COLUMN <> ? INDEX_COLUMN not in (?,?,...,?) |
不等于操作不能使用索引 |
|
|
function(INDEX_COLUMN) = ? INDEX_COLUMN + 1 = ? INDEX_COLUMN || ‘a‘ = ? |
经过普通运算或函数运算后的索引字段不能使用索引 |
|
|
INDEX_COLUMN like ‘%‘||? INDEX_COLUMN like ‘%‘||?||‘%‘ |
含前导模糊查询的Like语法不能使用索引 |
对于使用like的查询，‘aaa%‘ 会使用到索引，查询如果是‘%aaa‘不会使用到索引。 explain select * from dept where name like ‘研发部%‘; -- 不会使用索引 explain select * from dept where name like ‘%研发部‘; |
|
INDEX_COLUMN is null |
B-TREE索引里不保存字段为NULL值记录，因此IS NULL不能使用索引 |
|
|
NUMBER_INDEX_COLUMN=‘12345‘ CHAR_INDEX_COLUMN=12345 |
在做数值比较时需要将两边的数据转换成同一种数据类型，如果两边数据类型不同时会对字段值隐式转换，相当于加了一层函数处理，所以不能使用索引。 |
如果列类型是字符串，那一定要在条件中将数据使用引号引用起来。否则不使用索引。(添加时,字符串必须‘‘) -- 会应用索引 explain select * from dept where name = ‘研发部‘; -- 不会使用索引并且报错 explain select * from dept where name = 研发部; |
|
a.INDEX_COLUMN=a.COLUMN_1 |
给索引查询的值应是已知数据，不能是未知字段值。 |
|
|
对于创建的组合索引，只要查询条件使用了最左边的列，索引一般就会被使用，不是使用的第一部分，则不会使用索引 |
组合索引都是从第一个字段开始找起，看第一个条件字段是否是组合索引的第一个字段，如果是则使用索引，否则不使用 |
alter table dept add index name_loc (name, loc); explain select * from dept where name = ‘研发部‘; explain select * from dept where name = ‘研发部‘ and loc = ‘大厦10楼1001‘; -- 不会使用索引 explain select * from dept where loc = ‘大厦10楼1001‘; |
|
如果条件中有or，即使其中有条件带索引也不会使用。 |
-- 我们把组合索引删除，然后只在name上加入索引 alter table dept drop index name_loc; alter table dept add index name_index (name); -- 使用了索引 explain select * from dept where name = ‘研发部‘; -- key为NULL explain select * from dept where name = ‘研发部‘ or loc = ‘大厦10楼1001‘; |
|
|
注： 经过函数运算的字段要使用索引可以使用函数索引，这种需求建议与DBA沟通。 |
||
如果MySQL估计使用全表扫描要比使用索引快，则不使用索引。
我们一般在什么字段上建索引？
这是一个非常复杂的话题，需要对业务及数据充分分析后再能得出结果。主键及外键通常都要有索引，其它需要建索引的字段应满足以下条件：
1、字段出现在查询条件中，并且查询条件可以使用索引；
2、语句执行频率高，一天会有几千次以上；
3、通过字段条件可筛选的记录集很小，那数据筛选比例是多少才适合？
这个没有固定值，需要根据表数据量来评估，以下是经验公式，可用于快速评估：
小表(记录数小于10000行的表)：筛选比例<10%；
大表：(筛选返回记录数)<(表总记录数*单条记录长度)/10000/16
单条记录长度≈字段平均内容长度之和+字段数*2
例如：emp表中有600万的数据，单条记录长度 ≈ (7+6+6+3+8+4+1+10+7+6） + 11 * 2 = 70
筛选返回记录数就需要小于 6000000 * 70 / 10000 / 16 = 3625 左右即可
在emp的name字段中添加了索引，查看索引筛选比例如下，351小于预期值3625，说明在这个字段上建立索引是非常合理的
如何知道SQL是否使用了正确的索引？
简单SQL可以根据索引使用语法规则判断，复杂的SQL不好办，判断SQL的响应时间是一种策略，但是这会受到数据量、主机负载及缓存等因素的影响，有时数据全在缓存里，可能全表访问的时间比索引访问时间还少。要准确知道索引是否正确使用，需要到数据库中查看SQL真实的执行计划。
有些时候，我们只是访问表中的几个字段，并且字段内容较少，我们可以为这几个字段单独建立一个组合索引，这样就可以直接只通过访问索引就能得到数据，一般索引占用的磁盘空间比表小很多，所以这种方式可以大大减少磁盘IO开销。
如：select id,name from company where type=‘2‘;
如果这个SQL经常使用，我们可以在type,id,name上创建组合索引
create index my_comb_index on company(type,id,name);
有了这个组合索引后，SQL就可以直接通过my_comb_index索引返回数据，不需要访问company表。
切记，性能优化是无止境的，当性能可以满足需求时即可，不要过度优化。在实际数据库中我们不可能把每个SQL请求的字段都建在索引里，所以这种只通过索引访问数据的方法一般只用于核心应用，也就是那种对核心表访问量最高且查询字段数据量很少的查询。
SQL执行计划是关系型数据库最核心的技术之一，它表示SQL执行时的数据访问算法。由于业务需求越来越复杂，表数据量也越来越大，程序员越来越懒惰，SQL也需要支持非常复杂的业务逻辑，但SQL的性能还需要提高，因此，优秀的关系型数据库除了需要支持复杂的SQL语法及更多函数外，还需要有一套优秀的算法库来提高SQL性能。
目前ORACLE有SQL执行计划的算法约300种，而且一直在增加，所以SQL执行计划是一个非常复杂的课题，一个普通DBA能掌握50种就很不错了，就算是资深DBA也不可能把每个执行计划的算法描述清楚。虽然有这么多种算法，但并不表示我们无法优化执行计划，因为我们常用的SQL执行计划算法也就十几个，如果一个程序员能把这十几个算法搞清楚，那就掌握了80%的SQL执行计划调优知识。
查看索引的使用情况
show status like ‘Handler_read%‘;
大家可以注意：
handler_read_key:这个值越高越好，越高表示使用索引查询到的次数。
handler_read_rnd_next:这个值越高，说明查询低效。
这时我们会看到handler_read_rnd_next值很高，这是因为我们前面没有加索引的时候，做过多次查询的原因.
MyISAM：Mysql5.5默认的MySQL存储引擎。如果应用是以读操作和插入操作为主，只有很少的更新和删除操作，并且对事务的完整性要求不是很高。其优势是访问的速度快。
InnoDB：Mysql5.6默认的MySQL存储引擎，提供了具有提交、回滚和崩溃恢复能力的事务安全。但是对比MyISAM，写的处理效率差一些并且会占用更多的磁盘空间。
Memory：数据存在内存中，服务重启时，数据丢失
MyISAM： 在插入数据时，默认放在最后. ,删除数据后，空间不回收.(不支持事务和外键)
InnoDB 支持事务和外键
对应我们程序员说，常用的存储引擎主要是 myisam / innodb / memory,heap 表
如果选用小原则:
1.如果追求速度，不在乎数据是否一直保存，也不考虑事务，请选择 memory 比如存放用户在线状态.
2.如果表的数据要持久保存，应用是以读操作和插入操作为主，只有很少的更新和删除操作，并且对事务的完整性要求不是很高。选用MyISAM
3.如果需要数据持久保存，并提供了具有提交、回滚和崩溃恢复能力的事务安全,请选用Innodb
对于Innodb：
1，将要导入的数据按照主键排序
2，关闭唯一性校验，set unique_checks=0
3，,关闭自动提交，set autocommit=0
当创建了索引并且索引正常的工作，但性能仍然不好，那就可能是产生了索引碎片，需要进行索引碎片处理。
optimize table table_name;
标签：rop 建议 col 表示 .com 一个 uniq 主机 崩溃恢复
原文地址：https://www.cnblogs.com/tufujie/p/9650224.html
