命名规范：mysql
1表名，字段名，索引名称使用小写字母，数字采用下划线进行分割sql
2.表名采用模块名3个缩小字符 ‘前缀’以后顺序为代表数据库
3.表名，字段名不超过32个字符缓存
4.存储尸体数据的表，名称使用名词，单数并发
5.索引 采用‘inx’开头分布式
6.不使用保留字函数
7.存储实体表间多对多关系，名称建议采用‘noun_verb_noun’好比‘member_like_tag’高并发
在sql语句中保留字一概使用大写性能
字符串使用单引号优化
好比：
SELECT id,title FROM xiaoqu WHERE id=1
SELECT id,title FROM xiaoqu WHERE areacoe=’10002’;
错误写法：
-- 错误
select ID, title from XiaoQu where id = 1
SELECT id, title FROM xiaoqu WHERE areacode = "000100010001"
关于表的设计
默认使用innodb存储引擎
字符集使用utf-8
>charset 为‘utf-8’;校验规则 collation ‘utf_gereral_ci’
效率优先，提示性能
适当的牺牲范式，加入冗余
会增长代码复杂度
关于正确的使用时间类型：
精确到秒 采用timestamp
精确到时间 使用date
通常不适用datetime
每一个表都应该含有插入时间和更新时间 这个字段
不容许用字符串去存储时间
字段尽可能定义为not null
给默认值 ‘’
为何要这样作的缘由，进行查询的优化，可能这个字段会添加索引（为null状况下，会额外增长建立索引的开销） 含有null的复合索引无效
相似于性别这样的固定状态的东西 优先使用enum和set
enum占用一个字节，转为数值进行运算
set视节点定，最多使用8个字节
用好数值类型
原则：适用就好，越小越好
> TINYINT< SMALLINT < MEDIUMINT < INT < BIGINT
>
> 1 Byte/2 Bytes/3 Bytes/4 Bytes/8 Bytes
> FLOAT（4B）/DOUBLE（8B）
>
> DECIMAL（M,D） (M+2 B)
关于金钱这样常常参与运算的数据类型使用整形，不适用浮点数类型
> 例如金额能够用分为单位，而后采用 `INT`。若是依然要以元为单位，能够采用 `DECIMAL`。
数值类型和字符串类型进行比较
数值类型的效率更高，查询更快速，占用空间小
### 使用 INT UNSIGNED 来存储 IPv4 地址
> 使用 `INET_ATON` 将 IP 地址的字符串形式转换成数字形式；使用 `INET_NTOA` 将 IP 地址数字形式转换成字符串形式，以便查看。
>
> 当要查询某段的 IP 时，请参考如下示例：
### 不直接存储图片、音频、视频等大容量内容
> 请使用分布式文件系统来存储图片、音频、视频等内容。数据库里只存储文件的位置。
### 少用并拆分TEXT/BLOB
> TEXT类型处理性能远低于VARCHAR
为何尽可能不要使用text/blob这样的字段
强制生成硬盘临时表
浪费空间
varchar(65535)=>64K
如需使用请拆分到独立的表进行存放；
一张表中若是有不少的字段，是坏的设计
请考虑io高效，表修复，alter快/高并发
> 一个表有不少不少字段，是坏设计的味道。请再认真考虑设计是否正确。
> IO高效/表修复快/Alter快/高并发
> 以1G Size 500W Rows来评估
>
> - 顺序读取需N秒
> - 单行不超过200Byte
> - 单表不超50个INT字段，不超20个CHAR（10）字段
> - 单表字段数上限控制在20-50个
关于索引：
合理的建立索引：
索引的做用，优化查询
减慢更新
索引的添加综合评估数据的密度和数据的分布
结合核心sql优先考虑覆盖索引
### 使用数字主键
> 存储实体数据的表，其主键应该是数字类型。
### 不使用联合主键
> 存储实体数据的表，不使用联合主键。
> 存储实体表间多对多对应关系的表（仅有两个字段）容许例外。
### 不使用外键
> 全部的表不创建外键约束。
### 联合索引字段数不超过 5 个
> 一个联合索引的字段数太多，极可能是设计得很差，还很难符合命名的规范。
### 前缀索引长度不超过 8 个字符
> 对字符串类型的字段创建索引，采用前缀索引，且长度不超过 8 个字符。
### 不使用负向查询
> 负向查询是指，若是查询条件描述的是不要什么数据，其他的都要。例如 `!=`、`<>`、`NOT EXISTS`、`NOT IN` 以及 `NOT LIKE` 等就是负向查询，它们利用索引将会很辛苦。
### 一次查询的结果集不超过 100 行
> 必要时使用 `LIMIT 100`
### LIMIT m, n，其中 m 应当小于 500
> 使用 `SELECT ... LIMIT offset, row_count` 或者 `SELECT ... LIMIT row_count OFFSET offset` 时，当 offset 小于 500 时，容许使用。
>
sql
-- 容许
SELECT ... FROM property WHERE broker_id=? ORDER BY update_time LIMIT 40, 20
-- 不容许
SELECT ... FROM property WHERE areacode=? ORDER BY update_time LIMIT 4000, 20
避免使用count()函数；
> 能不使用就不使用，尽可能用其余方法来解决。
-- 正确
SELECT 1 FROM propertys WHERE broker_id=? LIMIT 1
-- 错误
SELECT COUNT(*) FROM propertys WHERE broker_id=?
在代码中能够经过获取size(),或者length得到长度
### 一次 COUNT() 可能扫描的行数应当确保小于 500 行
> `COUNT()` 函数须要扫描全部的结果集以后才能得出结果。而结果集的大小须要业务知识来判断（`EXPLAIN` 方法只能来来检验某一个条件下的当前状况）。所以须要使用 `COUNT()` 查询的代码应当通过审阅。
为何使用count(*) 除非真的想统计nullable的字段；
### 不在索引列作运算
> 不在索引列进行数学运算或函数运算
> - 没法使用索引
> - 致使全表扫描
举例：
root:xxx_db> select BrokerId from ajk_propertys where proid-100=101960636;
1 row in set (5.11 sec)
尽可能不要再数据库上作运算
复杂的sql运算转移到程序端cpu
简单实用mysql
### 同数据类型的列值比较
> 原则：数字对数字，字符对字符
> 字符列与数值类型比较
> 数值列于字符列比较
> - 同时转换为双精度进行比较
> 字符列于数值列比较
> - 字符列整列转数值，不会使用索引
sql
-- 禁止
SELECT id FROM property WHERE NOW() - update_time < 3600
SELECT id FROM property WHERE update_time + 3600 > NOW()
-- 改成
SELECT id FROM property WHERE update_time > NOW() - 3600
sql
-- 禁止
SELECT id FROM property WHERE CHAR_LENGTH(title) > 20
sql
-- 假设字段 property.status 的类型为 TINYINT
-- 禁止
SELECT id FROM property WHERE status = '1'
-- 改成
SELECT id FROM property WHERE status = 1
### 禁止隐式类型转换
> 不只在查询条件中禁止隐示类型转换，`INSERT`，`UPDATE` 也不容许隐式类型转换。
```
sql
-- 假设字段 property.status 的类型为 TINYINT
-- 禁止
INSERT INTO property (..., status) VALUES (..., '1')
UPDATE property SET status = '1' WHERE id = '43'
-- 改成
INSERT INTO property (..., status) VALUES (..., 1)
UPDATE property SET status = 1 WHERE id = 43
### 禁止使用 % 前导查询
> 尽可能不使用 `LIKE` 查询，不得不用的状况下也禁止使用 `%` 前导查询。
> - 使用不了索引
> - 致使全表扫描
### 禁止SQL语句拼接
> 应用程序不能有拼接语句出现
拒绝3B
大sql（拆分）
大事物 (contrller 不适用事物，在service层开启)
大批量（使用load data）
> 大SQL VS 多个简单SQL
>
> - 传统设计思想，BUT Mysql NOT
> - 一条SQL只能在一个CPU运算
> - 1000+ QPS的高并发中，1秒大SQL可能把数据库都堵死
> 拒绝大SQL，拆解成多条简单SQL
> - 简单SQL缓存命中率更高
> - 减小锁表时间，特别是MYISAM
> - 用上多CPU
> 不一样字段，将or改成union
> - 减小对不一样字段进行 or 查询
> - Merge index 每每很弱智
保持事物链接尽可能短小
即开即用，用完就关
减小锁资源占用
不破坏一致性的前提小，使用多个短事物代替长事物；
> 统一字符集为UTF8
> 禁用子查询
> - 大部分状况优化较差
> - 特别是Where中使用IN id的子查询
> - 通常可用JOIN改写
### 约定类规范（二）
> 永远不在程序端显示加锁
> - 永远不在程序端对数据库显式加锁
> - 外部锁对数据库不可控
> - 高并发是灾难
> - 极难调试和排查
> 可采用事务操做
```举例：Select GET_LOCK(‘str’)```### 约定类规范（三）> 请不要使用存储过程> 请不要使用trigger