myql索引

1、查询一个表的索引：
show index from game_record;

show keys from game_record;

2、显示表的列信息
show COLUMNS from game_record;

3、显示表的状态
show table status like 'game_record';



添加索引（唯一）：
ALTER TABLE `table_name` ADD UNIQUE 'index_name' ( `column` ) 

添加普通索引：
ALTER TABLE `table_name` ADD INDEX 'index_name' ( `column` ) 

添加多列索引 
ALTER TABLE `table_name` ADD INDEX 'index_name' ( `column1`, `column2`, `column3` )

分析查询条件是否使用索引：
EXPLAIN select * from game_record where game_id in (80171);

添加前缀索引：
ALTER TABLE `lottery_game_banner` ADD UNIQUE BANNER_URL2 ( `BANNER_URL`(6));

设置自增：

alter table tablename modify columnname  bigint(11)[类型] auto_increment; 

1、当 出现 服务器 对 多个 索引 做 相交 操作 时（ 通常 有 多个 AND 条件）， 通常 意味着 需要 一个 包含 所有 相关 列 的 多列 索引， 而 不是 多个 独立 的 单列 索引。

2、当 服务器 需要 对 多个 索引 做 联合 操作 时（ 通常 有 多个 OR 条件）， 通常 需要 耗费 大量 CPU 和 内存 资源 在 算法 的 缓存、 排序 和 合并 操作上。 特别是 当 其中 有些 索引 的 选择性 不高， 需要 合并 扫描 返回 的 大量 数据 的 时候。 更重 要的 是， 优化 器 不会 把这 些 计算 到“ 查询 成本”（ cost） 中， 优化 器 只 关心 随机 页面 读取。 这 会使 得 查询 的 成本 被“ 低估”， 导致 该 执行计划 还不 如 直 接走 全 表 扫描。 这样做 不但 会 消耗 更多 的 CPU 和 内存 资源， 还可能 会 影响 查询 的 并发 性， 但如 果是 单独 运行 这样 的 查询 则 往往 会 忽略 对 并发 性的 影响。 通常 来说， 还 不如 像 在 MySQL 4. 1 或者 更早 的 时代 一样， 将 查询 改写 成 UNION 的 方式 往往 更好。 如果 在 EXPLAIN 中看 到有 索引 合并， 应该 好好 检查 一下 查询 和 表 的 结构， 看 是不是 已经 是 最优 的。 也可以 通过 参数 optimizer_ switch 来 关闭 索引 合并 功能。 也可以 使用 IGNORE INDEX 提示 让 优化 器 忽略 掉 某些 索引。
3、在 一个 多列 B- Tree 索引 中， 索引 列 的 顺序 意味着 索引 首先 按照 最 左列 进行 排序， 其次 是 第 二列， 等等。 所以， 索引 可以 按照 升序 或者 降序 进行 扫描， 以 满足 精确 符合 列 顺序 的 ORDER BY、 GROUP BY 和 DISTINCT 等 子句 的 查询 需求。

4、前缀 索引 是一 种 能使 索引 更小、 更快 的 有效 办法， 但 另一方面 也有 其 缺点： MySQL 无法 使用 前缀 索引 做 ORDER BY 和 GROUP BY， 也 无法 使用 前缀 索引 做 覆盖 扫描。

5、只有 当 索引 的 列 顺序 和 ORDER BY 子句 的 顺序 完全 一致， 并且 所有 列 的 排序 方向（ 倒序 或 正 序） 都 一样 时， MySQL 才能 够 使用 索 引来 对 结果 做 排序。 如果 查询 需要 关联 多 张 表， 则 只有 当 ORDER BY 子句 引用 的 字段 全部 为 第一个 表 时， 才能 使用 索引 做 排序。 ORDER BY 子句 和 查找 型 查询 的 限制 是 一样 的： 需要 满足 索引 的 最 左 前缀 的 要求； 否则， MySQL 都 需要 执行 排序 操作， 而无 法 利用 索引 排序。

有 一种 情况下 ORDER BY 子句 可以 不满足 索引 的 最 左 前缀 的 要求， 就是 前导 列为 常量 的 时候。 如果 WHERE 子句 或者 JOIN 子句 中 对 这些 列 指定 了 常量， 就可以“ 弥补” 索引 的 不足。
6、这个 查询 在 y inventory_ id 列 上有 多个 等于 条件。 对于 排序 来说， 这也 是一 种 范围 查询： ... WHERE rental_ date = '2005- 05- 25' AND inventory_ id IN( 1, 2) ORDER BY customer_id。

7、事实上， MySQL 的 唯一 限制 和 主 键 限制 都是 通过 索引 实现 的

8、冗余 索引 和 重复 索引 有 一些 不同。 如果 创建 了 索引（ A， B）， 再创 建 索引（ A） 就是 冗余 索引， 因为 这 只是 前一 个 索引 的 前缀 索引。 因此 索引（ A， B） 也可以 当作 索引（ A） 来 使用（ 这种 冗余 只是 对 B- Tree 索引 来说 的）。 但是 如果 再创 建 索引（ B， A）， 则 不是 冗余 索引， 索引（ B） 也不 是， 因为 B 不是 索引（ A， B） 的 最 左 前缀 列。 另外， 其他 不同 类型 的 索引（ 例如 哈 希 索引 或者 全文 索引） 也 不会 是 B- Tree 索引 的 冗余 索引， 而无 论 覆盖 的 索引 列 是什么。
9、冗余 索引 通常 发 生在 为 表 添加 新 索引 的 时候。 例如， 有人 可能 会 增加 一个 新的 索引（ A， B） 而 不是不是 扩展 已有 的 索引（ A）。 还有 一种 情况 是将 一个 索引 扩展 为（ A， ID）， 其中 ID 是 主 键， 对于 InnoDB 来说 主 键 列 已经 包含 在 二级 索引 中了， 所以 这也 是 冗余 的。

大多数 情况下 都不 需要 冗余 索引， 应该 尽量 扩展 已有 的 索引 而 不是 创建 新 索引。 但也 有时候 出于 性能 方面 的 考虑 需要 冗余 索引， 因为 扩展 已有 的 索引 会 导致 其 变得 太大， 从而 影响 其他 使用 该 索引 的 查询 的 性能。
例如， 如果 在 整数 列 上有 一个 索引， 现在 需要 额外 增加 一个 很长 的 VARCHAR 列 来 扩展 该 索引， 那 性能 可能 会 急剧下降。 特别 是有 查询 把这 个 索引 当作 覆盖 索引， 或者 这是 MyISAM 表 并且 有很 多 范围 查询（ 由于 MyISAM 的 前缀 压缩） 的 时候。
10、在前 面的 InnoDB 的 示例 表中， 因为 二级 索引 的 叶子 节点 包含 了 主 键值， 所 以在 列（ A） 上 的 索引 就 相当于 在（ A， ID） 上 的 索引。 如果 有 像 WHERE A= 5 ORDER BY ID 这样 的 查询， 这个 索引 会很 有 作用。 但 如果 将 索引 扩展 为（ A， B）， 则 实际上 就 变成 了（ A， B， ID）， 那么 上面 查询 的 ORDER BY 子句 就 无法 使用 该 索引 做 排序， 而 只能 用文 件 排序 了。

11、有两 个 工具 可以 帮助 定位 未使 用的 索引。 最简单 有效 的 办法 是在 Percona Server 或者 MariaDB 中 先 打开 userstates 服务器 变量（ 默认 是 关闭 的）， 然后 让 服务器 正常 运行 一段时间， 再通过 查询 INFORMATION_ SCHEMA. INDEX_ STATISTICS 就能 查到 每个 索引 的 使用 频率。
12、我们 总是 尽可能 让 MySQL 使用 更多 的 索引 列， 因为 查询 只能 使用 索引 的 最 左 前缀， 直到 遇到 第一个 范围 条件 列。尽可 能将 需要 做 范围 查询 的 列 放到 索引 的 后面， 以便 优化 器 能使 用尽 可能 多的 索引 列。