设为首页 收藏本站
查看: 1215|回复: 0

[经验分享] 数据库设计及维护的一些心得 -- SQL Server篇

[复制链接]

尚未签到

发表于 2016-11-8 08:03:57 | 显示全部楼层 |阅读模式
  数据库的设计与程序的设计一样,如果设计不合理其性能以及可维护性就很差,而且可能给编程带来一些不便,根据设计的一些数据库,总结以下建议,也有可能不对,以后慢慢学习吧。
  1. 合理拆分数据表。 表太大太小都不合适,如果一个表的字段太多,则数据库的性能就会受到影响,可以将字段使用较频繁的字段放到一个表,很少用到的字段放到另外一个表,在必要时通过联合查询获得所有信息。
  2. 合理选择数据类型。 数据类型的选择不仅影响数据库的性能,而且影响到数据库所占存储空间的多少。尽量使用较短的数据类型,因为类型越短使用计算机的指令处理起来就越快,而且占用更少的存储空间,但前提是保证数据库能够满足要求,如:nvarchar,varchar如果存储的数据只是一些ASCII字符则用varchar,而不用nvarchar,如果需要多国语言字符,则最好用nvarchar以保证兼容性;尽量使用定长数据类型,如vachar和char,如果变化不是太大则用char,查询起来速度更快;使用数值类型而尽量不用text类型,因为int类型在计算机的汇编语言中是可以直接处理的,处理起来速度要比用text类型的快很多。
  3. 为数据库提供合适的默认值。 数据库字段如果设置为可为空,如果不添加默认值则默认为null,而null类型如果在编程时不做特殊处理会产生很多预想不到的错误,如使用null与其它值进行运算,则会得到null,而null与任何值进行比较都是null,这样可能造成预想不到的计算错误;另外,在编程时如果对null进行转换或者按照预想的类型进行操作则会产生错误或抛出异常。所以最安全的方法就是设置合理的默认值。
  4. 创建合适的索引。 对那些经常作为查询条件、排序的列,要创建索引,以提高数据库操作时查询的速度,但不必要的索引反而会占用更多的存储空间,并且会对数据库的性能具有负面的影响。
  5. 使用存储过程。 存储过程可以很好地把程序和数据库两层划清界限,实现明确的三层结构;在性能上,因为存储过程是在服务器上已经编译过的二进制代码,使得执行速度也比执行SQL语句速度快,还有,如果SQL语句比较长,还需要占用更多的传输时间。
  6. 保证字段名称的一致性。 在不同的表中建立了外键关联的字段名称要和主键名称保持一致,提高数据库的可读性,便于日后维护。
  在设计完成以后,对数据库的维护也是必不可用的,如果维护不利可能造成很多不必要的麻烦,养成好的习惯对工作是大有裨益的,下面是我维护数据库的一些心得。
  1. 定期自动备从数据库。 因为谁都不能保证程序运行不出错、服务器不出错、硬盘不会坏,更不能保证管理员在维护数据库的时候不会执行一些错误命令,定期自动备份数据库至少可以让您恢复到上一个版本,不至于遭受丢失所有数据的毁灭性灾难。
  2. 使用事务(Transaction)。在紧张的工作中,管理员进行管理操作时难免会执行一些不期望的Delete,update,alter甚至drop命令,可能会给数据库造成毁灭性的灾难,如果您在每运行一段SQL命令时都新建于一个事务,这样可以通过rollback命令恢复错误操作前的状态,否则,可能对数据库造成毁灭性的伤害,让你欲器无泪。
  3. 操作停止并备份数据库。 如果你正在操作的数据库可以临时停止,最好停止服务器,然后对服务器进行独占方式的操作,这样你可以知道哪些东西被修改了,如果联机操作可能多个人进行了操作来不及恢复又被别人修改了;操作前备份一个完整的数据库,一旦进行了错误的不可逆操作,你还可以恢复到旧数据库,可能前面一部分工作白做了,但至少您的数据还在,“留得青山在不怕没柴烧”嘛!
  4. 保存您的日志。 设计好数据库后,看一下您的日志是否全部保存,如果您的存储空间允许还是保存所有的操作日志,一时哪天你不小心进行了错误操作,还可以通过日志进行恢复。
  可是不管你多么小心,总是会犯一些错误,或大或小,一时犯了错误怎么办呢?首先要冷静,不要头一热就呆在那儿了,这样有可能让你错失了弥补过失的机会,很惭愧,我就犯过一次这样的错误,至今记忆犹新。下面是我对犯错后处理的一些心得:
  1. 如果您使用了transaction,这没有问题,请执行rollback命令。
  2. 如果你没有使用transaction命令,这样执行rollback是没用的,但不要怕,不是不可挽回。如果你使用的是离线的数据库,而且有备份,这个也很好办,恢复到你的旧数据库;如果是在线的数据库,而且数据有更新,没有备份数据库,这是不要着急,立即停止数据库(当然,你的停止操作可能让用户蒙受损失,你要权衡一下,是任你那些数据丢失,还是冒着让用户丢失一些数据的危险去恢复你错误操作中丢失的数据),然后复制一个数据库,要全部复制,包括日志文件,然后想办法通过日志进行恢复。[注]此时千万不要收缩数据库,特别是进行了delete和drop操作,如果一收缩数据库那你不小心删除的那些数据或表就彻底完蛋了,老天爷也帮不了你了。
  对SQL Server,可以使用LogExplorer查看数据库的日志文件,然后通过日志尽量恢复你丢失的数据。
  我那次丢失数据就是停止数据库停得太晚了,错误操作后刚好被领导叫去开回,回来之后停止了数据库,但是日志是滚动的,当时我操作时的日志已经被覆盖掉了,痛苦!

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-297108-1-1.html 上篇帖子: SQL发邮件 下篇帖子: SQL Server 索引基础知识(2)----聚集索引,非聚集索引 (转合)
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表