bewitch-真假难辨
数据库相关规范
1.
使用
utf8mb4
字符集
2.
所有表、字段必须写清中文注释
3.
金额字段禁止使用小数存储（单位：分）
4.
禁止使用字段属性隐式转换（如
：
“
WHERE ms_no = 1234
< br>”
ms_no
为字符串类型）
5.
尽量不使用负向查询（
NOT
、
!=
、
<>
、
!<
、
!>
、
NOT
IN
、
NOT
LIKE
等）
6.
禁止使用外键，如有完整性约束，需要应用程序控制
7.
禁止使用程序配置文件内的账号访问线上数据库
8.
禁止非
DBA
对线上数据库进行写操作
9.
开发、测试、线上环境分离
10.
所以提交的
< br>SQL
语句必须经过测试
11.
禁止存储大文件或大照片
12.
库名、表名、字段名：小写，
下划线分割，不超过
32
个字符，必须见名知意，禁止拼
音英文混用
13.
表必须有主键
14.
必须把字段定义为
NOT
NULL
并设置默认值
15.
必须使用
varchar
（
20
）来存储手
机号
16.
单表索引控制在
5
个以内，单索引字段数不许超过
5
个
a)
索引的使用。
(1)
尽量避免对索引列进行计算。如计算较多，请提请管理员建立函数索引。
(2)
尽量注意比较值与索引列数据类型的一致性。
(3)
对于复合索引，
SQL
语句必须使用主索引列
(4)
索引中，尽量避免使用
NULL
。
(5)
对于索引的比较，尽量避免使用
NOT=
（
!=
）<
/p>
(6)
查询列和排序列与索引列次序保持一致
(7)
禁止在更新频繁、区分度不高（如：性别）的字段上建立索引
(8)
建立组合索引，必须把区分度高的字段放在前面
17.
禁止使用
SELECT *
，只获取必要的字段
18.
禁止使用
INSERT INTO
t_xxx VALUES(xxx)
，必须指定插入的列名
19.
禁止在
WHERE
条件的属性上使用函数或表达式
20.
禁止
%
开头的模糊查询
21.
禁止使用
OR
条件
22.
应用程序必须捕获
SQL
异常，并作出相应处理
23.
逻辑删除代替物理删除
24.
选择最有效的表名、查询条件顺序（从右到左）
25.
减少访问数据库的次数
26.
SQL
中的关键字均使用大写字母，数据表最好起别名
27.
查询条件中“
>=
”代替“
>
”
28.
等号两边使用空格，逗号后使用空格
29.
多表操作必须使用别名
30.
整条语句必须写明注释，关键
逻辑单独书写注释，说明算法、功能
a)
注释风格：注释单独成行、放在语句前面。
(1)
应对不易理解的分支条件表达式加注释；
(2)
对重要的计算应说明其功能；
31.
32.
33.
34.
(3)
过长的函数实现，应将其语句按实现的功能分段加以概
括性说明；
(4)
每条
SQL
语句均应有注释说明（表名、字段名）
。
(5)
常量及变量注释时，应注
释被保存值的含义
(
必须
)
，合法取值的范围
(
可选
)
(6)
可采用单行
/
多行注释。
（
--
或
/* */
方式）
尽量减少使用
ORDER
BY
与
GROUP
BY
操作影响性能
所有写入上线程序
的
SQL
语句，都必须提取保存并写清注释与所在位置模块
创建共享
SQL
语句，并写清帮助文档
避免变量循环赋值、使用
索引设计准则
1.
应该对
WHERE
子句中经常使用的列创建索引
2.
应该对经常用于连接表的列创建索引
3.
应该对
ORDER BY
子句中经常使用的列创建索引
4.
不应该对小型的表
（仅使用几个页的表）
创建索引，
这是因为完全表扫
描操作可能比使
用索引执行的查询快
5.
单表索引数不超过
6
个
6.
不要给选择性低的字段建单列索引
7.
充分利用唯一约束
8.
索引包含的字段不超过
5
个（包括
include
列）
9.
不要给选择性低的字段创建单列索引
10.
SQL SERVER
对索引字段的选择性有要求，如果选择性太低
SQL
SERVER
会放弃使用
11.
不适合创建索引的字段：性别
、
0/1
、
TRUE/FALSE
12.
适合创建索引的字段：
ORDERID
、
UID
等
13.
充分利用唯一索引
14.
唯一索引给
SQL Server
提供
了确保某一列绝对没有重复值的信息，
当查询分析器通过唯
一索
引查找到一条记录则会立刻退出，不会继续查找索引
15.
表索引数不超过
6
个
16.
表索引数不超过
6
个（这个规则只是携程
DBA
经过试验之后制定的。
。
。
）
17.
索引加快了查询速度，但是却会影响写入性能
18.
一个表的索引应该结合这个表
相关的所有
SQL
综合创建，尽量合并
19.
组合索引的原则是，过滤性越好的字段越靠前
20.
索引过多不仅会增加编译时间
，也会影响数据库选择最佳执行计划
SQL
查询
1.
禁止在数据库做复杂运算
2.
禁止使用
SELECT *
3.
禁止在索引列上使用函数或计算
4.
禁止使用游标
5.
禁止使用触发器
6.
禁止在查询里指定索引
7.
变量
/
参数
/
关联字段类型必须与字段类型一
致
8.
限
制
JOIN
个数
9.
限制
S
QL
语句长度及
IN
子句个数
10.
11.
12.
13.
14.
15.
16.
17.
尽量避免大事务操作
关闭影响的行计数信息返回
使用
UNION
ALL
替换
UNION
查询大量数据使用分页或
TOP
递归查询层级限制
NOT
EXISTS
替代
NOT IN
尽量
避免使用
OR
运算符
增加事务异常处理机制
禁止在数据库做复杂运算
1.
XML
解析
2.
字符串相似性比较
3.
字符串搜索（
< br>Charindex
）
4.
复杂运算在程序端完成
5.
禁止使用
SELECT *
6.
减少内存消耗和网络带宽
7.
给查询优化器有机会从索引读取所需要的列
8.
表结构变化时容易引起查询出错
禁止在索引列上使用函数或计算
假设
在字段
Col1
上建有一个索引，则下列场景将可以使用到索引
：
[Col1]=3.14
[Col1]>100
[Col1] BETWEEN 0
AND 99
[Col1] LIKE ‘abc%’
[Col1] IN(2,3,5,7)
LIKE
查询的索引问题
1.[Col1] like “abc%”
–
index seek
这个就用到了索引查询
2.[Col1] like “%abc%”
–
index scan
而这个就并未用到索引查询
3.[Col1] like “%abc”
–
index scan
这个也并未用到索引查询
我想从上而
三个例子中，大家应该明白，最好不要在
LIKE
条件前面用模
糊匹配，否则就用
不到索引查询。
禁止使用游标
关系数据库适合集合操
作，也就是对由
WHERE
子句和选择列确定的结果集作集合操
作，游
标是提供的一个非集合操作的途径。
一般情况下，
游标实现的功能往往相当于客户端的一个
循环实现的功能。
游标是把结果集放在服务器内存，
并通过循环一
条一条处理记录，
对数据库资源
（特别是内
存和锁资源）的消耗是非常大的。
禁止使用触发器
触发器对应用不透明
（应用层面都不知道会什么时候触发触发器，
发生也也不知道，
感觉莫
名
……
）