身为开发人员，这些数据库合知识不掌握不合适( 五 ) _数据库

15 查询计划器可以报告数据库的信息查询计划器可以给出查询在数据库中的执行方式。它还会分析查询并在执行之前进行优化。计划期只能提供一些大致的估计。怎样才能得到下述查询的结果呢？
SELECT * FROM articles where author = "rakyll" order by title;有两种方式可以获取结果：

全表扫描：扫描表中的每一条记录，返回作者名字匹配的所有文章，然后排序
索引扫描：使用索引找到匹配的ID，获取这些行，然后排序

查询计划器的职责就是判断哪种方式最合适。查询计划器得到的信号很有限，因此可能会导致不理想的决定。DBA或开发者应该使用这些信息来诊断并对效率不高的查询进行调优。新版数据库可以调整查询计划器并进行自我诊断。慢查询报告、延迟问题报告、执行时间报告等也有助于优化查询。
查询计划器提供的某些指标可能很混乱，特别是有关延迟或CPU时间的指标。作为查询计划器的辅助，跟踪和执行路径工具也有助于诊断这些问题。不过并不是每个数据库都提供这些工具。

在线迁移非常复杂，但不是不可能实时在线迁移意味着从一个数据库迁移到另一个数据库，中途不停止服务，还要保证数据的正确性。如果在同种数据库之间迁移，那么在线迁移就能容易些，但如果使用新的数据库，再加上不同的性能要求和表结构，迁移就会变得更加复杂。
在线迁移有不同的模型，下面是其中一种：

开始对两个数据库进行双重写入。在此阶段，新数据库不会拥有所有数据，但新数据会出现在新数据库中。一旦对这一步充满信心，就可以继续进行第二步。
在两个数据库上同时启用读取路径。
主要使用新的数据库进行读写操作。
停止在旧的数据库上进行写入操作，但读取操作依然在旧的数据库上进行。此时，新的数据库并不包含所有新数据，在读取旧数据时，可能依然需要使用旧的数据库。
此时，旧的数据库是只读的。将新数据库中缺少的数据填入。迁移完成后，所有的读写路径都可以使用新的数据库，旧的数据库就可以移除了。

如果需要更多案例研究，可以阅读Stripe的这篇详尽的文章（https://stripe.com/blog/online-migrations）。

数据库的显著增长表明不确定性数据库增长会带来不可预料的规模问题。对数据库内部原理的理解越多，我们对于规模的预见就越少，但有些东西是无法预料的。
数据库增长会导致以前对于数据规模和网络容量需求的假设变得无效。这时就需要进行大规模结构修改、大规模操作改善、容量问题改善、重新考虑部署、迁移到其他数据库等方式来避免服务中断。
永远不要假设你只需要理解当前数据库的内部原理，因为规模会引发新的问题。无法预料的热点、不均衡的数据分布、无法预料的容量和硬件问题，日益增长的流量和新的网络分区，都会让你不得不重新考虑数据库、数据模型、部署模型和部署规模等问题。
原文链接：
https://medium.com/@rakyll/things-i-wished-more-developers-knew-about-databases-2d0178464f78
本文为CSDN翻译文章，转载请注明出处

【身为开发人员，这些数据库合知识不掌握不合适】