为什么Mysql explain extended中的filtered列值总是100

1. MySQL的统计信息非常少，只有表行数和索引列的唯一值数目，这使得MySQL的优化器经常不能对数据规模有一个正确的认识而给出性能不佳的执行计划。

2. MySQL的join *** 作的效率非常依赖于索引(我之前两次帮人调优MySQL的SQL语句都是在加索引)。并不是说PG的join不需要索引，只是不像MySQL缺了索引的反应那么大。上面那个MySQL执行了1分多钟的例子，加上索引后，不管是MySQL还是PG的执行时间都立刻降到10毫秒以内。所以，开发人员在设计表的时候应该对可能的查询方式做个评估，把该建的索引都建上（不能少建也不宜多建）。

3. 相比之下，PG不仅统计所有列的值分布，而且除了唯一值还有直方图，频繁值等等信息，支撑了PG的优化器做出正确的决策。猜测也是由于这个原因，PG社区认为PG的优化器已经足够智能，不需要把和Oracle类似的hint功能加到PG的内核里（因为hint可能会被人滥用，导致系统很难维护；不过，实在想用的话可以自己装pg_hint_plan插件）。

1. mysqldump： 最早，也是最成熟的逻辑备份工具，是 MySQL 原生的用来备份整个数据库实例、单个数据库、单张表的逻辑备份工具， 上手简单，学习成本几乎为 0。备份简单，恢复也简单。

比如导出单个数据库 ytt: mysqldump ytt >/tmp/ytt.sql；

恢复也非常简单：mysql </tmp/ytt.sql

缺点是备份速度慢。在整个备份过程中，是单线程运行；备份出来的数据集要恢复的话同样也是单线程运行，恢复速度也慢。除非对同一时刻的所有表单独备份出来，自己写额外脚本进行多线程恢复。

2. mysqlpump：MySQL 5.7 GA 后推出的 mysqldump工具的增强版。可以对同一个数据集多个线程并发备份，备份速度很快。

其他缺点和 mysqldump 一样。

3. MySQL Shell UTIL 对象附带的备份工具：随 MySQL 8.0.21 最新版本捆绑发布，自带多线程备份以及多线程恢复功能， 可以直接替代 mysqldump/mysqlpump。

dump_instance/dumpInstance 用来多线程备份 MySQL 整个单机实例 dump_schemas/dumpSchemas 用来多线程备份 MySQL 单个数据库 load_dump/loadDump 用来多线程恢复之前两个工具导出的数据集文件

---