数据库画像，怎么做？
点击蓝色“有关SQL”关注我哟
加个“星标”，天天与10000人一起快乐成长
图 | L
2008年，阿里提出去[IOE]的口号；
2014年，12306，去O上云；
2017年，联通首次3省去O上云；
2019年，陆金所脱O；
这里的O是指 Oracle 数据库。为什么脱[ O ],并不是本文重点。怎么脱才是！
大约2008年，那时我还在MES/ERP开发岗位上，做得热火朝天。foxpro + sql server 2000 的编程玩得如鱼得水。何止996,007我都愿意，单身有时间。
突然有一天，接到主管通知：
“ 大家准备下，我们要换 Oracle 了”
“啥子是 Oracle”
“宇宙最强数据库”
至今我还记得主管一脸憨笑。希望他也会记得我那张便秘的脸。
换就换咯，那怎么换呢，一张张表自己去建，自己去导数据么。后续我也不知道，谁拿钱谁做，反正我没拿到。既然项目是迁移完了，那肯定是有人做了的。一个信息办公室都你我大眼瞪小眼，别问了，谁都没做，是外包公司干的。
切到Oracle之后，我也没多想。反正不难吧。直到最近，看到这本书《Efficient Database Optimization -Architecture, Specification and SQL Skills》 又名《数据库高效优化》，我才想起来，异构数据库迁移，这事儿真没想过，可能真不是原本我想的那么简单。
去 O，你想好了？
从2008年喊口号去IOE，到现在2021年了，13年过去了，你们的 Oracle 还活着吗，如果要迁移，会做哪些工作呢？
评估迁移风险和工期 设计新架构 边设计边测试边上线
那这里面哪部分最重要呢？显然没第一步，往下都不能存在。如何有效评估风险和工期是难点。一定要迁移数据库的话，数据库画像跑不了。
具体来说，数据库画像可以分为这三个部分：
数据库物理结构 运行时统计信息 SQL 审核总结
干说，太抽象。我不想你们中途离场，所以先放个图，再解说。没耐心的，看个大概就行。后面有代码，直接上手撸。
后台回复“数据库画像”，拿Python代码，自制画像。该版权属于PingCAP
说明：挑重点讲，不废话
数据库物理结构：除了数据库本身的存储大小，尤其还要注意收集每日甚至每小时增量。增量统计信息，直接影响容量策略和备份策略
运行时统计信息:都知道Oracle有强悍的RAC集群，如果新切换的数据库不能支撑那么大的并发，其实架构是有很大必要调整的。比如分库，分表，读写分离。
SQL审核总结：这是预估工作量最难的地方。比如超长的SQL数量，PL/SQL方言的SQL有多少，3个表以上Join的SQL有多少，等等，都将影响工作量的评估。
以下规则，来自于 PingCAP: https://github.com/bjbean/oracle-estimate-report 你有权自定义各类阈值。
规则说明
· * 大表判断规则1_物理大小: 1000 M
· * 大表判断规则2_记录数: 1000000
· * SQL超长标准: 200 字符
· * ANTI SQL: 指包含关键字(not in、not exist)的语句
· * Oracle Syntax SqL: 指包含关键字(rowid、rownum、decode、partition、rullup、cube、sampling、rank、percentile、ntitle、top、bottom、period、lead、lag的语句
· * Join 3+ Table SQL: 关联3个及3个以上表的语句
· * SubQuery SQL: 包含子查询的语句
当有一天，你的老板也向你提出，“哎，我们把Oracle换了吧，怎么样？”我希望这篇文章，可以给你一些灵感。
往期精彩：