mysql数据库

MySQL数据库一般指MySQL，MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发。

mysql是目前网站以及APP应用上用得较多的一个开源的关系型数据库系统，可以对数据进行保存，分段化的数据保存，也可以对其数据进行检索，查询等功能的数据库。

默认的mysql数据库中存有一个库这个就是mysql的系统数据库，可以对其保存系统的数据包括mysql数据库的信息，数据库root账号，普通账号，以及数据库的名称，还有数据库的一些表还有一些数字型的数据类型结构都会有所保存。

mysql数据库的优点

（1）MySQL数据库是用C和C++语言编写的，并且使用了多种编辑器进行测试，以保证源码的可移植性。

（2）支持多个 *** 作系统例如：Windows、Linux、Mac OS等等。

（3）支持多线程，可以充分的利用CPU资源。

（4）为多种编程语言提供API，包括C语言、Java、PHP、Python语言等。

（5）MySQL优化了SQL算法，有效的提高了查询速度。

（6）MySQL内提供了用于管理，检查以及优化数据库 *** 作的管理工具。

（7）它能够作为一个单独的应用程序应用在客户端服务器网络环境中，也可以作为一个库嵌入到其他的软件中并提供多种语言支持。

在开始演示之前，我们先介绍下两个概念。

概念一，数据的可选择性基数，也就是常说的cardinality值。

查询优化器在生成各种执行计划之前，得先从统计信息中取得相关数据，这样才能估算每步 *** 作所涉及到的记录数，而这个相关数据就是cardinality。简单来说，就是每个值在每个字段中的唯一值分布状态。

比如表t1有100行记录，其中一列为f1。f1中唯一值的个数可以是100个，也可以是1个，当然也可以是1到100之间的任何一个数字。这里唯一值越的多少，就是这个列的可选择基数。

那看到这里我们就明白了，为什么要在基数高的字段上建立索引，而基数低的的字段建立索引反而没有全表扫描来的快。当然这个只是一方面，至于更深入的探讨就不在我这篇探讨的范围了。

概念二，关于HINT的使用。

这里我来说下HINT是什么，在什么时候用。

HINT简单来说就是在某些特定的场景下人工协助MySQL优化器的工作，使她生成最优的执行计划。一般来说，优化器的执行计划都是最优化的，不过在某些特定场景下，执行计划可能不是最优化。

比如：表t1经过大量的频繁更新 *** 作，（UPDATE,DELETE,INSERT），cardinality已经很不准确了，这时候刚好执行了一条SQL，那么有可能这条SQL的执行计划就不是最优的。为什么说有可能呢？

来看下具体演示

譬如，以下两条SQL，

A：

select * from t1 where f1 = 20

B：

select * from t1 where f1 = 30

如果f1的值刚好频繁更新的值为30，并且没有达到MySQL自动更新cardinality值的临界值或者说用户设置了手动更新又或者用户减少了sample page等等，那么对这两条语句来说，可能不准确的就是B了。

这里顺带说下，MySQL提供了自动更新和手动更新表cardinality值的方法，因篇幅有限，需要的可以查阅手册。

那回到正题上，MySQL 8.0 带来了几个HINT，我今天就举个index_merge的例子。

示例表结构：

mysql>desc t1+------------+--------------+------+-----+---------+----------------+| Field      | Type         | Null | Key | Default | Extra          |+------------+--------------+------+-----+---------+----------------+| id         | int(11)      | NO   | PRI | NULL    | auto_increment || rank1      | int(11)      | YES  | MUL | NULL    |                || rank2      | int(11)      | YES  | MUL | NULL    |                || log_time   | datetime     | YES  | MUL | NULL    |                || prefix_uid | varchar(100) | YES  |     | NULL    |                || desc1      | text         | YES  |     | NULL    |                || rank3      | int(11)      | YES  | MUL | NULL    |                |+------------+--------------+------+-----+---------+----------------+7 rows in set (0.00 sec)

表记录数：

mysql>select count(*) from t1+----------+| count(*) |+----------+|    32768 |+----------+1 row in set (0.01 sec)

这里我们两条经典的SQL：

SQL C：

select * from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2

SQL D：

select * from t1 where rank1 =100  and rank2 =100  and rank3 =100

表t1实际上在rank1,rank2,rank3三列上分别有一个二级索引。

那我们来看SQL C的查询计划。

显然，没有用到任何索引，扫描的行数为32034，cost为3243.65。

mysql>explain  format=json select * from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "3243.65"    },    "table": {      "table_name": "t1",      "access_type": "ALL",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "rows_examined_per_scan": 32034,      "rows_produced_per_join": 115,      "filtered": "0.36",      "cost_info": {        "read_cost": "3232.07",        "eval_cost": "11.58",        "prefix_cost": "3243.65",        "data_read_per_join": "49K"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))"    }  }}1 row in set, 1 warning (0.00 sec)

我们加上hint给相同的查询，再次看看查询计划。

这个时候用到了index_merge,union了三个列。扫描的行数为1103，cost为441.09，明显比之前的快了好几倍。

mysql>explain  format=json select /*+ index_merge(t1) */ * from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "441.09"    },    "table": {      "table_name": "t1",      "access_type": "index_merge",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "union(idx_rank1,idx_rank2,idx_rank3)",      "key_length": "5,5,5",      "rows_examined_per_scan": 1103,      "rows_produced_per_join": 1103,      "filtered": "100.00",      "cost_info": {        "read_cost": "330.79",        "eval_cost": "110.30",        "prefix_cost": "441.09",        "data_read_per_join": "473K"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))"    }  }}1 row in set, 1 warning (0.00 sec)

我们再看下SQL D的计划：

不加HINT，

mysql>explain format=json select * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "534.34"    },    "table": {      "table_name": "t1",      "access_type": "ref",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "idx_rank1",      "used_key_parts": [        "rank1"      ],      "key_length": "5",      "ref": [        "const"      ],      "rows_examined_per_scan": 555,      "rows_produced_per_join": 0,      "filtered": "0.07",      "cost_info": {        "read_cost": "478.84",        "eval_cost": "0.04",        "prefix_cost": "534.34",        "data_read_per_join": "176"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100))"    }  }}1 row in set, 1 warning (0.00 sec)

加了HINT，

mysql>explain format=json select /*+ index_merge(t1)*/ * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "5.23"    },    "table": {      "table_name": "t1",      "access_type": "index_merge",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "intersect(idx_rank1,idx_rank2,idx_rank3)",      "key_length": "5,5,5",      "rows_examined_per_scan": 1,      "rows_produced_per_join": 1,      "filtered": "100.00",      "cost_info": {        "read_cost": "5.13",        "eval_cost": "0.10",        "prefix_cost": "5.23",        "data_read_per_join": "440"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100) and (`ytt`.`t1`.`rank1` = 100))"    }  }}1 row in set, 1 warning (0.00 sec)

对比下以上两个，加了HINT的比不加HINT的cost小了100倍。

总结下，就是说表的cardinality值影响这张的查询计划，如果这个值没有正常更新的话，就需要手工加HINT了。相信MySQL未来的版本会带来更多的HINT。

五 索引分类

直接创建索引和间接创建索引

直接创建索引 CREATE INDEX mycolumn_index ON mytable (myclumn)

间接创建索引 定义主键约束或者唯一性键约束 可以间接创建索引

普通索引和唯一性索引

普通索引 CREATE INDEX mycolumn_index ON mytable (myclumn)

唯一性索引 保证在索引列中的全部数据是唯一的 对聚簇索引和非聚簇索引都可以使用

CREATE UNIQUE COUSTERED INDEX myclumn_cindex ON mytable(mycolumn)

单个索引和复合索引

单个索引 即非复合索引

复合索引 又叫组合索引 在索引建立语句中同时包含多个字段名 最多 个字段

CREATE INDEX name_index ON username(firstname lastname)

聚簇索引和非聚簇索引(聚集索引 群集索引)

聚簇索引 物理索引 与基表的物理顺序相同 数据值的顺序总是按照顺序排列

CREATE CLUSTERED INDEX mycolumn_cindex ON mytable(mycolumn) WITH

ALLOW_DUP_ROW(允许有重复记录的聚簇索引)

非聚簇索引 CREATE UNCLUSTERED INDEX mycolumn_cindex ON mytable(mycolumn)

六 索引的使用

当字段数据更新频率较低 查询使用频率较高并且存在大量重复值是建议使用聚簇索引

经常同时存取多列 且每列都含有重复值可考虑建立组合索引

复合索引的前导列一定好控制好 否则无法起到索引的效果 如果查询时前导列不在查询条件中则该复合索引不会被使用 前导列一定是使用最频繁的列

多表 *** 作在被实际执行前 查询优化器会根据连接条件 列出几组可能的连接方案并从中找出系统开销最小的最佳方案 连接条件要充份考虑带有索引的表 行数多的表内外表的选择可由公式 外层表中的匹配行数*内层表中每一次查找的次数确定 乘积最小为最佳方案

where子句中对列的任何 *** 作结果都是在sql运行时逐列计算得到的 因此它不得不进行表搜索 而没有使用该列上面的索引如果这些结果在查询编译时就能得到 那么就可以被sql优化器优化 使用索引 避免表搜索(例 select * from record where substring(card_no )=

&&select * from record where card_no like % )任何对列的 *** 作都将导致表扫描 它包括数据库函数 计算表达式等等 查询时要尽可能将 *** 作移至等号右边

where条件中的 in 在逻辑上相当于 or 所以语法分析器会将in ( ′ ′)转化为column= ′ or column= ′来执行 我们期望它会根据每个or子句分别查找 再将结果相加 这样可以利用column上的索引但实际上它却采用了 or策略 即先取出满足每个or子句的行 存入临时数据库的工作表中 再建立唯一索引以去掉重复行 最后从这个临时表中计算结果 因此 实际过程没有利用column上索引 并且完成时间还要受tempdb数据库性能的影响 in or子句常会使用工作表 使索引失效如果不产生大量重复值 可以考虑把子句拆开拆开的子句中应该包含索引

要善于使用存储过程 它使sql变得更加灵活和高效

lishixinzhi/Article/program/MySQL/201311/29603

---