【自爆系列】浅谈我对数据库性能注意事项的错误了解

对与数据库的性能，有很多注意事项

入行这些年，以为积累了这些就够了，也以为这些是对的，其实多为表面现象，似似而非

1：不要用select *，因为这影响性能，但是人懒，没办法，用了那么多select *，也没见死机不是

2：where 后面的东西要走索引，所以经常玩命的建立索引，反复的看查询分析器，到底走索引了没，单纯为了走索引而走索引，以至于出现

nG数据2nG的索引

3：小子加with（nolock）了没，服务器死锁了！没加赶快加，但是难免犯懒，这个东西加没加也缺乏有效的检测，经常这个人忘了加，哪个人忘了加我怎么知道，哎说多了都是泪

4：sql服务器主要的性能指标为CPU,和链接数，直到后来，才知道这些只是表现，sql服务器的主要指标是io，其次是cpu和连接数

5：为了提高性能，写一个老复杂老长的sql，后来才知道，这个老复杂老长的sql表面上性能高了，实际上反而降低了,尤其是并发来的时候的时候

6：项目的开始，必然是以一个数据库开始了，里面放了所有需要的表。。。。。。

直到有一次打电话给运维dba

                                                     问，我们要提高数据库稳定性改咋整？

                                                     运维回复：你要做读写分离还是要做主从还是要做啥呢，啪啦啪啦啪啦啪啦啪啦啪啦啪啦，

                                                     最后根据你们服务器io的表现，建议啥也别做自己优化程序吧，当时就想吧第一个创建数据库的人，第一个创建表的人（虽然已经离职N年了）拉出来，问：你当初建表的时候咋就不考虑这些呢？

从运维的角度，提高数据库稳定性的基本手段只能是读写分离（确保写入数据没问题，保持数据流畅通，不掉链子），一主多从或多主多从

参考 http://blog.csdn.net/wanmdb/article/details/7515277 这篇文章，

主从库之间是一种发布订阅的关系，发布者和订阅者之间并非实时同步的，通常会有几分钟的延时，更有甚者会有几个小时的延时。所以我们需要通过合理的使用来避开有延时这个问题。我们希望主库尽可能的少参与查询，来提高写的及时性；同时要让从库在不影响读出数据的准确及时的前提下尽可能的分担主库的压力

（PS:运维还说，做了主从或什么的，必须是整个数据库进行同步，而不是某几个表，同时，整个数据库表的结构的修改，新增或删除表有可能导致意外风险时同步失败等等啪啦啪啦啪啦啪啦）

从一个数据库变成多个一摸一样的数据库，是解决数据库稳定性

随之产生的问题就是延迟！！！！！！！！！！！！！！！！！！！！！

首先本人声明，本人还没做过基于mssql主从数据库上的程序，新浪sae的APP由于读写分离延迟太小忽略不计了，而且是mysql的

根据项目老大和运维dba的分析影响主从时候延迟的因素主要有

1：你这个主库写入的数据的速度快不快啊，如果快了，那就得把写的快的表和字段拆出去

2：你这个主库修改的速度快不快啊，如果快了，那就得把修改快的字段拆出去

3：你这个主库整体写入和修改的速度快不快啊，如果快了，那就得一分为二

4：你的这个查询啊，那些有group 等的都在那些表上，该拎出来的就拎出来

5：至于宽带、硬盘读写性能、cpu等我们都是无力改变的，就当做不知道吧

6：你们看着办吧

总而言之，言而总之，以前我对sql的性能总停留在 索引上和select * 上，这其实是不科学的表面现象，至少走没走索引你监控不了那个查询造成ip或cpu高了

sql服务器可以监控的指标

1：io 是否满载，是否出现sina（x） 那样的波浪线，频繁的满载

     ps：很多情况下，io频繁满载，例如周五，各个单位做数据汇总交差，管理员后来查询统计拉挂数据库服务器，进而拉挂前台展示站点。。。。

2：cpu是否满载，是否出现sina（x） 那样的波浪线，频繁的满载

    cpu：说实话你有没有在sql里面写死循环，没写死循环cpu应该没事

3：连接数是否满载，是否出现sina（x） 那样的波浪线，频繁的满载

   赶紧看看流量涨了没，是涨了多少，是以前的一倍还是2倍还是多少，如果少于3倍，问题必然出在1和2上

这3个要素也是运维或dba决定怎么搞数据库的主要指标，

话说基于主从结构的数据库改如何设计呢？

其实我也没设计过，最近我在折腾我自己的抓取站点，才第一次自己操刀给数据库分表，坑多路少。。。

根据运维和dba的意见（核心思想）----不管你做什么我们一年只给年干几次这样的操作！也就是主从设置什么的1年只设置几次，因为同步失败呀什么的就不管了。

根据我入行3年的个人经验整理如下（ps：这些均不考虑需要带锁的场景，我还没用过锁呢。。。。。）

1：以慢慢写为主的主库，例如博客园存放博文的表放的库，不可能出现1分钟1入100条数据的表

2：以快快读为主的读库，禁止使用各种锁，禁止使用各种表联合查询，禁止使用group等高io操作

3：以慢慢读为主的低并发库，例如各种要求时时查询（分钟级别），各种统计，各种查询

4：以快快写为主的库，这个库只作灾备切换处理，例如点击量统计、系统日志等

最后根据经过验，实现以上4点，没有搜索聚合数据这个工具是不行，刚开始了解lucene，了解的不多，欢迎高手拍砖。

最后就是关于orm

因为dba说，这个设置了，就不能随便新增表和修改表的结构了

随便应该是1小时改一次，不随便，应该是1各月弄一次，

鉴于此，肯定需要在所有表上新增备用字段，例如 50个 bigint，50个 字符串，表也得新增备用的，假设一个月操作一次，那就准备50张表，每个表50个bigint50个字符串，这个时候，字段的命名只能是a、B、c、d等等，你知道他们是什么意思吗？肯定不知道，这个时候，orm作为数据库和实体的对应关系就发挥了很大的作用

1 可以定义 a 是什么，价格、点击量等等

2 一张表可以分组映射很实体对象，方面修改查询部分字段，减少数据库对单个人的复杂度

其实orm在复杂查询下的价值不是很大，但是在数据库结构很复杂的情况下，orm的作用就很大了

不知道大家发现了没