一：大型表（记录1000条以上）一定要加主键。
二：主表表可以拆分为接报表和处理表，虽然查询的时候逻辑复杂了，但分散了数据，有效避免了死锁的发生。
三：主表中的字典数据最好用整型的代码存储。在查询的时候也用整型代码进行匹配，能极大的提供查询的速度。
四：字典表中如果存在上下级关系，可以采用格式字符串表示父子关系。如 02 是 0201的父级。
五：新增记录直接使用insert语句。更新记录直接使用update语句。虽然采用先delete后insert的方式进行数据插入和更新，能减少前台程序的代码量，但是这种方法在大表中极易引起互相的死锁。而且，对于触发器的编写也造成了很多不必要的困惑，反而降低了效率。
六：主记录号一定要充分预备位数。该记录号的数据类型因为长度固定，建议采用char（n）类型。因为char（n）的处理效率要比varchar高。但对应那些可变字符长度如地址，描述等字段为了避免数据库存储空间的浪费，易采用varchar类型。
七：主表中的触发器业务逻辑不易复杂。太复杂的触发器会给今后的功能扩展和系统维护造成障碍。建议使用可扩展的动态链接库实现业务逻辑。通过程序实现业务逻辑，虽然效率偏低，但可扩展性强。对于象那种马拉松式的项目强烈推荐。
八：在进行触发器或存储过程的调试中，添加的中间表和测试语句一定要及时删除。否则会对后期维护造成很多不必要的困惑和麻烦。（举手之劳，利人利己）。
九：事务是个双刃剑。在带来数据同步的同时，也带来了资源死锁的可能。所有事务中的逻辑一定要简洁明了。尽量不用游标。尽量避免对大表进行直接操作。
十：主记录号采用先读取后使用的原则，千万不要在保存的过程中在去读主记录号。因为保存数据需要时间，在保存的时候读取主记录号，会引起其它访问主记录号进程的死锁。
十一：业务表和统计报表完全分离。最理想的方式是在数据保存的时候直接进行数据运算，然后把保存结果存放在中间表中。这样可以有效地避免定时整表扫描。当然，这样作也可能会造成保存时的速度缓慢，但是可以通过增加临时表的方式来解决。
十二：日期类型一定要采用Datetime类型。可以大大加快查询速度。避免了字符串格式变换带来的资源消耗。
十三：在设计字典表的时候，保持内容和代码顺序的一致。在程序中尽量采用固定的代码来作查询，避免代码内容的二次关联带来的资源消耗。
十四：如果查询结果不要求很实时精确，尽量采用不加锁的select语句。
十五：尽量避免通过有条件的定时表扫描来获得指定的记录。如中查找预约记录，就是通过不停的表扫描来获得，资源消耗很厉害。
评论