轻松精通数据库管理之道——运维巡检之三（结构设计）
前言
做好日常巡检是数据库管理和维护的重要步骤，而且需要对每次巡检日期、结果进行登记，同时可能需要出一份巡检报告。
本系列旨在解决一些常见的困扰：
- 不知道巡检哪些东西
- 不知道怎么样便捷体检
- 机器太多体检麻烦
- 生成报告困难，无法直观呈现结果
前面两篇对服务器软硬件配置、数据库概况进行了巡检，下面我们要对数据库的一些结构设计进行检查，这些检查主要针对系统开发初期一些不优化的结构设计或在系统不断有新功能增加或运维变动而产生的结构变化。
物理结构概览
在【检查项】-【全部】中查看每个数据库的信息，当数据库结构未通过常规检查，平台会提示出警告。
注：检查信息主要包含不规范的表、缺失索引、无索引外键、没有使用的索引、重复索引、老化的索引。
不规范的表
在【数据库】-【不规范的表】中检查系统中表是否存在有不规范设计。这些不规范设计主要包含无聚集索引，使用旧数据类型，聚集索引的列是随机增长的（GUID，uniqueidentifier类型）
注:
1.微软建议在表中都建议有聚集索引。聚集索引除了可以提高查询性能之外，还可以按需重新生成或重新组织来控制表碎片。
2.在 Microsoft SQL Server 的未来版本中将删除 ntext、text 和 image 数据类型。 请避免在新开发工作中使用这些数据类型，并考虑修改当前使用这些数据类型的应用程序。 请改用 nvarchar(max)、varchar(max) 和 varbinary(max)。
3.聚集索引本身是要排序的，而GUID（uniqueidentifier类型）这样插入数据时导致过多的页拆分。
缺失索引
（图略）
数据库设计中索引是性能的一大关键，当数据库缺失大量索引，那么也必然导致数据库的性能很差。
无索引外键
（图略）
-
对主表数据操作时（如删除），需要到外键表中查找校验，如果缺少外键索引可能导致全表扫描，严重影响性能。
-
当在查询中组合相关表中的数据时，经常在联接条件中使用外键列，方法是将一个表的 FOREIGN KEY 约束中的列与另一个表中的主键列或唯一键列匹配。索引使 数据库引擎可以在外键表中快速查找相关数据，提升性能。
没有使用的索引
（图略）
随着开发和优化的进行，很多人会对数据库进行索引的创建操作，很多时候创建了一个较优的联合索引或者覆盖索引，会让原本单列的索引失去使用的场景，这部分索引会出现在，长时间未使用的索引中，建议删除。
重复索引
（图略）
随着开发和优化的进行，很多人会对数据库进行索引的创建操作，那么页难免会产生一些功能相近或相同的索引，索引本身也是有维护成本，在更新、插入、删除时会有一定的开销，那么重复的索引只会增加这部分维护开销。
老化的索引
（图略）
索引维护是配置常规维护任务之一，随着数据的不断写入和变更，会产生大量的索引碎片，缺少维护任务的索引，无法及时重新组织索引数据，导致索引低效，甚至失效。
程序设计结构概览
1.在【检查项】-【结构设计】中查看会话信息和执行计划，当设计结构未通过常规检查，平台会提示出警告。
注：检查信息主要会话隔离级别、是否存在带有事务的长时间会话、执行计划中是否存在隐式转换。
会话信息
1.在【会话】-【空闲会话】中查看会话信息。
注：主要关注，长时间未关闭会话和长时间未关闭并带有事务的会话。长时间带有事务的会话可能是因为程序连接泄露导致，长时间带有事务会阻塞其他会话的正常进行，造成系统卡死等严重性能问题。
2.在【会话】-【概览】页中查看会话详细信息，主要关注事务隔离级别。
事务隔离级别简述：事务隔离级别主要控制查询（共享锁），隔离级别越高并发能力就越差。（详细信息请参见：平台技术资料，最佳配置）
隐式转换
存在隐式转换的执行计划：语句存在隐式转换导致性能消耗，或不能使用索引。
注：隐式转换常发生在表设计的字段类型（varchar）优先级别低于程序传递的参数类型（nvarchar）
在【执行计划】-【隐式转换】页中查看具体信息。
总结
整个程序和数据库是否稳定、高效和结构设计的好坏密不可分，在巡检过程中，结构设计时比较重要的一部分。很多时候运维人员和设计人员、开发人员沟通不畅、专业技能有差距，所以结构设计常常出现问题。
