书接上回。今天讲述的是一些误解。
误解1：空间不足删除数据。
假如有100万数据，占空间10G。现在删除50万数据（delete from这样），占空间几何？（假设数据每行数据大小大致相等）非数据库人员认为是5G,包括很多开发人员也这样认为。一般来说OLTP数据库来说，还是10G。因为delete了数据，空间上留下了空的行，但是并没有进行收缩。这个原理今天不展开了。所以大部分开发会在应用程序中乐此不疲的使用delete，满以为这样做，能删除数据，表不会很大。其实然并卵。
我有一次帮别人处理问题，就遇到他们每次都是全表删除，自以为表不大。但是就是这样只有几条的表，却有几十个G。每次执行都很慢。我给他处理了一下，原来2200秒的，现在0.2秒了。我顺带说这样对磁盘不好啊。他说你怎么知道的？上个月刚坏了一块硬盘。坏了一块硬盘。坏了一块硬盘。（本来就不能这样干，没用）
误解2：连接数越多越好。有一次安装一个测试环境，开发说连接数不够。我说100多还不够吗？开发说别人我10万个连接。
其实每个连接都要占用数据库资源，每个数据库不一样，我们通常来说差不多平均也要5M，也就是说1000个连接，什么都不做，就静静的连着，5个G就没有了。关键还不干活。好像觉得连接数多了可以并行处理，其实绝大多数情况下，我只看到几个连接是活动的。当达到几十个的时候，基本数据库也就告别“自行车了”。（除非是像一体机这样的神兽）。一般物理机连接数几百还能抗，但是已经很卡或者不能用了。虚拟机的十几个活动会话已经卡的不能用了。因为这个时候如果去看CPU和IO，基本是CPU满负荷，硬盘嗷嗷叫。连接数设置1万，就像吾皇万岁万万岁一样，没见过哪个真到这样的（一体机除外）。中原王朝最长寿命的乾隆88岁。
结果很多数据库应用连接数过高（本质还是SQL写的太差），导致资源耗尽而死。
误解3：表越大越慢。经常有人说MySQL超过1000w性能急剧下降。当然也有说其他数据库也是超过多少就很慢。说这话的一定是%%去查的。因为这样的确几千万逐行扫描是慢。这个只能说暴露了SQL写的差，其他说明不了什么。当然也有说需求如此，那只能说是管理水平差，其他也说明不了什么。我记得有一次DTCC大会有人问，周彦伟（我国第一个MySQL方向的ACED）1000万的表查询很慢怎么办？周总说，看看索引吧。其实当今的数据库和硬件，只要SQL用到索引，并且结合分页等。都是很快的，如果是点查都是几毫秒甚至不到1毫秒可以完成（和redis没差多少）。
误解4：单机不遵守开发规范，性能极差，锁都不知道怎么锁的。寄希望于上分布式数据库解决这些问题。
其实分布式数据库是单机的延伸，也要遵守数据库开发规范，甚至比单机的还要多。如果单机的锁都搞不明白是怎么回事，那么分布式数据库的锁，只能是让情况变得雪上加霜。当然分布式还是好的，至少还是一个体系能保证数据一致性。没有分布式数据库直接来分不分表。最终一致性没有保障的前提下，发现做的越多错的越多。最好查问题都不知道怎么下手。总算知道问题了，但是无法解决。因为一切归于分库无法利用数据库锁，而锁在单机时候就没搞明白，觉得锁不好。熟不知，没有锁更不好。
未完待续。
