随着客户各类数据分析业务的丰富和发展，数据库所承载的查询数量和复杂度都会持续增加，特别是对于数据库表结构的设计和优化，往往对数据库整体使用成本和查询性能有较大影响。想做好相关的库表结构设计和优化，用户往往需要关注以下几个部分：
- 需要了解引擎架构：用户往往需要对数据库引擎的存储和计算架构特点有一定的了解，才能和业务的数据分布特征以及业务场景特征完美结合，来进行数据建模，从而设计出符合引擎架构特点的表结构。
- SQL特性差异较大：即席查询的SQL往往特性差异较大，包括参与Join的表个数、Join条件、分组聚合的字段个数以及过滤条件等。
- 数据特征变化较快：用户的数据分布特征是会随着业务特征的变化而变化的，如果一直按照最初的建模方式和SQL语句，也是无法保障能发挥出SQL引擎的最大优势，数据特征或者业务模型的变化，都会导致SQL性能回退。
基于此，AnalyticDB MySQL版（新一代云原生实时数据仓库，语法兼容MySQL，以下简称ADB）为用户提供了高效且智能化的「智能建模诊断与优化」功能，直观的为用户提供相关调优的建议，降低用户使用成本，提高用户使用ADB的效率。本功能通过对用户SQL查询所使用到的数据表、索引、查询性能的历史信息进行统计，在此基础上进行智能分析并提供调优建议，本文介绍如何查看和和使用相关建议。
调优建议类型
冷热分层优化：
- 弹性实例支持数据存储的冷热分离配置（https://help.aliyun.com/document_detail/189727.html），冷数据存储到低成本的存储介质上，可以降低整体使用成本，本项建议分析数据表的使用情况，对于长期未使用的数据表，提出移至冷存的建议。
- 本建议的优化单位为一个数据表的整体，优化后数据表存储成本会降低；若再次查询该数据表，查询时间会增长。
很多业务 BI 分析查询具有强烈的周期性，很多数据表只有每个月、每个季度才会用到一次。像这样低频使用的数据表完全可以利用弹性实例提供的冷热数据分离存储的功能，在不使用的时候先移至冷存，降低存储成本。只在使用的时候才移至热存。
如上图所示，我们对弹性实例利用冷热分离存储建议可以获得的潜在收益进行了统计。可以看到60%的实例可以通过本建议的提示，将 15 天未使用的数据表移至冷存，节省 3 成以上的热存空间，降低存储成本。
无效索引优化：
- AnalyticDB MySQL版通过增加数据索引提高扫描数据的速度，达到查询性能的提示（https://help.aliyun.com/document_detail/296045.html）。数据索引也会占用磁盘空间，提高使用成本。本项建议分析数据索引的使用情况，对于长期未使用的数据索引，提出考虑删除的建议。
- 本建议的优化单位为一个列的数据索引，优化后数据索引的存储成本会降低；若查询再次使用改数据列进行过滤操作，查询时间会增长。
数据库建表时默认对全部数据列进行索引，这样可以极大的简化用户建表时的负担，无需用户提前预知业务查询的特性，保证查询性能最大化。但与此同时，实际业务往往只会用到几个列的索引进行查询和数据过滤，长期无用的索引反而增加了存储的成本。
如上图所示，我们对线上实例利用索引优化建议可以获得的潜在收益进行了统计。可以看到50%的实例可以通过本建议的提示，将 15 天未使用的索引进行删除，节省 3 成以上的热存空间，降低存储成本。
分布键优化：
- AnalyticDB MySQL版的查询执行依赖分布式计算和存储的架构（https://help.aliyun.com/document_detail/211215.html），特别是进行JOIN、聚合等计算时，往往需要通过网络传输对数据进行分布，合理选择数据表分布列可以减少网络开销，提高查询效率。如果数据表的分布列和实际查询的数据分布特征不一致，就会造成查询时间增长、查询效率降低等问题。本项建议分析数据查询实际需要使用的分布列与数据表定义的分布列的差异，提出考虑改变数据表分布列的建议。
- 分布键优化建议的优化单位为表，也即对整张表的分布列进行优化，优化后涉及到该表分布列的相关查询，性能一般会增加；若同一张表同时有其他涉及到非分布列的查询存在，就会导致分布列选择的矛盾，我们的算法会按照整个库级别查询最优目标，使用优化算法选择每张表的最优分布列。
- 下面列举两个简单的例子，我们的测试表A和表B分别有5百万行的数据，第一个例子，对于JOIN查询：
SELECT*FROM A INNER JOIN B ON A.order_id= B.order_idLIMIT1000;
我们对比两种情况：1. 表A按照自增id分布；2.表A按照JOIN列order_id分布，这里表B假设已经按照order_id分布。对于这两种情况，分别执行查询，测试结果是表A按照JOIN列order_id分布，查询时间会快大约30%，原因就是JOIN前无需进行网络传输对数据重分布。第二个例子，对于聚合查询：
SELECT order_id, max(total)FROM(SELECT order_id, sum(amount)AS total FROM A GROUPBY order_id )
我们对比两种情况：1. 表A按照自增id分布；2.表A按照聚合列order_id分布。对于这两种情况，分别执行查询，测试结果是表A按照聚合列order_id分布，查询时间会快大约60%，同样是因为节省了数据重分布的网络传输时间，计算节点可以直接在本地进行聚合操作。
用户界面指南
用户通过控制台左边栏「诊断与优化」 -> 「库表结构调优」分页访问该功能
可采纳建议的查看
可用优化建议如下图所示，每条建议包含建议 ID, 建议类型，建议对应的 SQL, 给出建议的原因，建议收益估算等信息。其中建议对应的SQL为应用建议需要变更的表和相应定义等。建议优化收益为基于历史数据统计的预估值，非实时统计的准确值，仅供参考。
一键应用优化建议
用户点击“一键应用”按钮，即表示同意采纳该优化建议，并将相应变更的 SQL 下发到实例进行执行，下发后改建议会出现在“已采纳建议”分页中。下发的建议如同在客户端执行相应 SQL，不支持撤销操作，请谨慎使用。
已采纳建议的查看
用户可以按采纳建议日期和时间查询已采纳的建议；建议 SQL 下发后，需要数据表完成 build 方可完成应用，build 操作是数据库系统按一定规则自动触发的，未触发前，相应建议处于“运行中”的状态，触发后变为“已完成状态”
开启和关闭优化建议功能
用户可以通过开关按钮，打开和关闭优化建议的显示功能。
欢迎使用，并提供您宝贵的建议和反馈！
本功能现面向有意向使用的客户进行开放，欢迎进钉钉支持群联系我们。
