数据库之泪第五章节
前几天正在群里谈及一些技术问题，接到有人求助请看看MySQL数据库。连上去看看，大量的表锁。其实一般来说我们OLTP数据库都是行锁的。如果动不动就表锁了，这活没法干了。但是锁这种在不同数据库不同场景下处理还不一样，比如MySQL在默认的RR下，没有索引或者没用到索引的DML就是表锁。这种是不懂或者不了解数据库的人会无意中犯下的错误。
曾经在一个群里看到有人问，大家MySQL事务隔离级别用的是什么？有一个人说了句RR。我接了一句：“RR”厉害了。然后一堆人复制我的话。群主问RR厉害在哪里？我就说了“MySQL在默认的RR下，没有索引或者没用到索引的DML就是表锁。” 群主觉得这是开发的基本素质。没这样做的还要留着吗？ 哎，其实吧。这种在国内是普遍现象。
不仅仅是这种没意识的。还有的就是有意识的犯错误。
故意1：有个附件表，每天改，有的有附件，有的没附件。不知道怎么搞的就是总是错了。于是乎每天凌晨定时清空所有，然后一个个对一下，一个个去更新。诸位看看，是不是要是控制的好点，不至于这么费劲吧？就这一个动作比系统一天其他总的产生的归档日志都多。也就是说一天主要的压力不是业务，而是刷这个表。
故意2：全量insert一个表，但是第二天要把这个表全部删除，再重新insert进去。因为不知道哪些变了？（常见于不知道上游什么变化了，或者不想知道，只想偷懒）所以越来越慢。
故意3：ETL全量拿取数据。在上游表结构变化后或者上游删除数据后再或者在上游变了但是下游实在不知道的情况下，定期全量。
对于故意2和故意3来说，其实想想数据库的全量备份和增量备份就知道了。为什么要有增量备份？就是为了在保障数据一致的前提下，代价最小化。
故意4:上游强大，不告诉变化。下游被动接受全量，然后自己比较差异。这种是实属无奈，属于管理问题。系统对接，上游不管下游死活。与故意2不同，故意2是以后者为准。
故意5:下游强大，懒得做变化判断。主动全量拿上游，然后自己比较差异。这种是无知。系统对接，下游不管上游死活。使劲拿数据，上游被消耗尽了也不管。与故意3不同的是，这种只拿固定的1-2个表。
故意6：每小时拿前一个月的数据（精确到秒），虽然不是全量。但是每次拿的数据99%以上甚至100%都是无用功。
以上我一定没有穷举出所有场景，能力有限，经历有限。但是我相信一定还会有其他的，只是我没见过。对于故意的来说，基本出发点就是一个字：懒（除了故意4，这是上游懒）。系统稳定不稳定不是开发的责任。（画外音在大厂不是这样定义的，应用开发写的不好，就是开发的问题。）
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/637517/viewspace-2898308/ ，如需转载，请注明出处，否则将追究法律责任。
