“去O”，是近些年来一直很火的一个话题，随之也产生了各种疑惑，包括现有数据库评估、技术选型等。去O是项系统工程，需要做好充分的评估。本文通过自研工具，生成数据库画像，为去O评估提供一手数据，希望给大家带来借鉴。
一、常见疑惑很多公司在考虑去O的时候，经常面临这样的问题—"对自己的数据库不够了解"，也不免有这样一些疑惑：
[管理者]
数据库去O成本高嘛？
工作量大不大？
工期长吗？
是否存在什么风险？
[架构师]
使用MySQL能承载现有业务规模嘛？
是否有什么技术风险？
是否需要引入分库分表嘛？
是否需要引入缓存嘛？
研发复杂度高嘛？
需要投入多大工期？
数据访问特征如何？
迁移前后对比数据量大吗？
[开发者]
复杂SQL多嘛？
改造量是不是很大？
是不是使用Oracle方言、专有对象，需要改造？
等等
面对上面这些问题，就需要快速了解现有Oracle的对象、语句、访问特征、性能表现等，并据此评估技术方案、迁移方案以及后续的工作量等。也就是说，需要给我们的数据库进行“画像”。基于上面的数据库画像，对去O工作全周期进行指导，包括以下方面都将大有裨益：
决策阶段：整体难度、成本（人财时）、技术风险
架构阶段：技术方案、对象结构、性能评估
研发阶段：兼容性、复杂度、测试
迁移阶段：结构迁移、数据迁移、数据校验
正是基于此类需求，有些公司推出评估产品，例如阿里的数据库和应用迁移服务（简称 ADAM），但此类产品往往需要部署agent，上传分析包等，对于安全比较敏感的企业不太可行。我所在的公司在两年前启动去O工作时，也面临此问题。故特意开发个绿版小程序，可在本地运行，方便评估工作。
地址：https://github.com/bjbean/oracle-estimate-report
二、设计思路收集并汇总 Oracle 数据库信息，包含环境、空间、对象、访问特征、资源开销及SQL语句等六方面信息，全面覆盖数据库实际运行状况。为信息收集更有针对性，工具通过参数设置部分阈值。通过运行命令行，收集信息后生产WEB版评估报告，以可视化的方式直观体现出来。不仅可作为去O评估依据，亦可作为后续改造的数据参考。
三、画像解读下面针对报告数据进行解读，并对常见的去O选型-MySQL进行说明。
3.1 概要信息显示收集的目标的概要信息，包括IP、实例、用户等。需注意分析时间，脚本会提取数据库执行特征（24小时内），因此建议在业务高峰之后运行。
3.2 空间信息
空间大小是数据库选型需重点考虑的指标之一，也会影响到后续迁移。如库规模较大，应考虑做分拆处理。拆分的原则就是尽量控制单库规模。一般可遵循如下拆分优先原则：
1）业务层垂直拆分在应用层面，将数据按照不同的业务条线进行拆分。例如电商平台中按照订单、用户、商品、库存等拆分。各自拆分的部分，业务内聚，无强数据依赖关系。
2）业务层水平拆分在同一业务内部，对数据建立生命周期管理，进行数据冷热分层。针对不同层的数据访问特点不同，可做进一步拆分。例如电商平台中，针对订单可分为活跃订单(二周内，可退换货)、非活跃订单(二周至半年期，客服可受理)、历史订单（半年以上）。
3）应用层分库分表若经过上述拆分单个库的规模仍然较大，可考虑使用分库分表技术。通常的做法是引入数据库中间层，逻辑上虚拟出一个数据库，但物理上划分为多个数据库。这是一种不太“优雅”的方案，因为很难做到应用透明。也就是说，必须在研发方面有所妥协，牺牲一部分数据库能力。常见技术方案上可分为：Client、Proxy、SideCar三类，现多推荐使用Proxy模式（容器部署可考虑SideCar模式）。
4）基础层分布式数据库较“分库分表”方式更为彻底的是直接使用分布式数据库。它提供了一种可承载更大规模（容量、吞吐量）的解决方案。近些年来，分布式数据库已逐渐成熟，推广落地；并开始在关键场景中尝试使用。
3.3 对象信息
针对Oracle中对象，在改型中各有不同的考虑要点。报告中给出汇总数据，也可给出明细数据方便查询。
1）表