最近在协助用户进行系统重构，RDS测试选型自然成为了本项目的一个重点，但是用户在测试不同规格的时候发现大规格的实例性能居然不如小规格，4C32G规格性能比8C64G规格高出10%，其性能监控也是非常的正常，4C32G规格是8C64G规格资源消耗的一半，TPS也是相当，那问题到底出现在那里？CPU消耗对比：TPS监控：从监控上没有看出端倪后，我们怀疑用户的业务测试模型可能不一致，所以采取分析SQL审计日志来分析问题，把top sql拿出来对比就可以一目了然问题的所在，所以重新开启压测，使用我们的专家分析系统来分析SQL日志，结果让人大吃所惊，一条truncate 语句映入眼：可以看到truncate 语句在8C64G的规格中执行慢了30秒左右，这个时间恰好是整个测试相差的时间，为什么规格越大反而DDL truncate越慢？这个问题其实在5.5版本存在的一个问题，可以参考在2015年双11时候写过的一篇文章：RDS弹性升级后性能反而下降的案例，所以解决方案只要把实例升级到5.6就可以了。在这次问题排查中使用了很重要的SQL审计日志来发现两个实例规格的性能差异，该功能已经集成到RDS的专家系统中，帮助用户更好的分析使用数据库。 ...继续阅读 (28)

周一的时候有一个客户反馈自从上次rds重启后，慢查询特别多，有大量响应时间在1～3秒的请求，后端的工程师介入调查，发现随便建一个最简单的表，插入数据都需要300ms。一开始的时候怀疑可能是网络延迟导致的，客户测试了从ecs到rds的网络延迟，测试结果网络延时不到1ms，那问题到底出现在那里？在MySQL中可以使用profile去查看SQL的执行时间主要消耗在哪里，所以我们来看一下profile：mysql> show profiles;+———-+————+—————–+| Query_ID | Duration   | Query           |+———-+————+—————–+|        1 | 0.09211525 | select * from d ||        2 | 0.03659925 | select * from d ||        3 | 0.22665400 | select * from d ||        4 |  ...继续阅读 (23)

在前三期介绍了RDS for MySQL参数优化，锁问题以及延迟优化最佳实践之后，本期将介绍存储空间相关的最佳实践。存储空间是RDS很重要的一个指标，在RDS的工单问题中，空间问题的咨询可以排在top 5，当RDS的实际使用空间超过了购买的空间后，实例就会被锁定了，这样就会导致应用无法再写入，更新数据，造成应用的报错。在RDS的控制台中可以设定空间的报警阀值，当实例空间到达报警阀值后用户就会收到报警短信，这个时候用户则需要对判断当前的空间增长是否合理。如果增长合理则需要对实例的进行弹性升级，这里需要指出的是弹性升级分为两种，一种是本地升降级，该类升级是实例所在的主机磁盘空间充足，足以容纳升级所需的空间，这个时候的升级非常迅速，而且对应用毫无影响；第二种是跨机升级，该类升级时实例所在的主机剩余磁盘空间不足以容纳升级所需的空间，那么就需要将实例迁移到其他磁盘资源足够的主机上，这时需要的时间可能会很长，取决于实例的总空间大小，因为迁移过程涉及将备份拷贝还原到新的主机上，同时还要考虑新实例与旧实例的数据同步问题，那么这一些因素都会导致升级时间较长，最后升级结束时候数据库中的已有连接会全部断开（备注：高安全访问链路没有此问题）。如果增长不合理，则需要进行快速的判断问题出现在那，则需要我们了解RDS的空间组成到底包括了哪些。在RDS控制台中可以看到空间的组成分为了5部分，分别为：磁盘总空间，数 ...继续阅读 (49)

秒杀最早来自天猫双11各种商品的促销活动中，现在已经有很多业务场景在使用，比如抢红包，抢票等。其特点有三高：瞬时并发高，数据一致性高，热点更新频度高。这样三高的场景下往往给数据库造成极大的压力，大量更新数据库中的同一行，这样必然会产生锁等待，导致数据库的性能急剧下降的问题，很容易容易出现雪崩效应。笔者记得有一年春节，一个电视台定时在整点发放红包，结果由于压力太高，导致更新数据库红包数额的请求全部堆积，业务全部挂掉，面对这样的情况我们当时也束手无策。面对秒杀业务的场景，数据库成为了底层系统中最重要的瓶颈点，阿里经过几年的沉淀也诞生了很多的技术手段来进行优化，这里我们就重点讲一下底层数据所做的优化。当大量的并发更新同一条记录时，使用排队的方式来保证高并发下热点记录更新依然能保持较好的性能，为threads_running设置一个硬上线，当并发超过此值是，拒绝执行sql，保护MySQL，我们将这个称之为高水位限流，这样就给数据库加上了一层限流的功能，使得数据库不被瞬间的高爆发请求打爆。高水位限流实现：监控系统status变量threads_running，当满足拒绝条件，拒绝执行sql，返回用户：MySQL Server is too busy，判断逻辑在dispatch_command中，sql解析之前。增加的系统variables：1.threads_running_ctl_mode ...继续阅读 (57)

请赐简历至：xuancan@taobao.com， 感谢您对加入我们公司有兴趣，我们希望能早日和您共事。阿里云-数据库专家-SQL Server / MySQL / Postgresql岗位描述：1.    负责阿里云云产品数据库的设计与规划2.    负责阿里云数据库产品的改进与建设3.    负责阿里云数据库产品的自动化运维4.    负责对客户提供优质的数据库技术服务岗位要求：1.    熟悉各个云产品，了解数据库云产品的形态与现状，熟悉AWS，阿里云，AZURE等相关数据库产品。2.    精通SQL Server/MySQL / Postgresql 等数据库(之一）的运行机制和架构体系，精通数据库架构与设计，对数据库解决方案的优劣和适用场景有深入的理解，能够根据具体场景合理进行数据库选型和模型设计。3.    SQLServer专家：熟悉Windows操作系统，掌握C#，Python，Powershell等语言中的一种，可以通过程序自动化处理工作中遇到的各种问题，显著提升工作效率，具备良好的编程风格。4.    SQLServer专家：深度掌握SQL SERVER优化原理，能够从全链路上定位性能瓶颈（网络、CPU、IO、操作系统等），提升数据库使用体验。5.    具有强大的内心，具备强烈的抗压能力，具有优秀的客服第一的意识。6.    良好的团队协作能力，善为人师，渴 ...继续阅读 (45)

最近一段时间处理了较多锁的问题，包括锁等待导致业务连接堆积或超时，死锁导致业务失败等，这类问题对业务可能会造成严重的影响，没有处理经验的用户往往无从下手。下面将从整个数据库设计，开发，运维阶段介绍如何避免锁问题的发生，提供一些最佳实践供RDS的用户参考。一．设计阶段：在数据库设计阶段，引擎选择和索引设计不当可能导致后期业务上线后出现较为严重的锁或者死锁问题。(1).表引擎选择使用myisam，引发table level lock wait。从5.5版本开始，MySQL官方就把默认引擎由myisam转为innodb，这两种引擎的主要区别：由于myisam引擎只支持table lock，在使用myisam引擎表过程中，当数据库中出现执行时间较长的查询后就会堵塞该表上的更新动作，所以经常会碰到线程会话处于表级锁等待（Waiting for table level lock）的情况，严重的情况下会出现由于实例连接数被占满而应用无法正常连接的情况CREATE TABLE `t_myisam` (`id` int(11) DEFAULT NULL) ENGINE=MyISAM DEFAULT CHARSET=utf8；Query |111 | User sleep              | select id,sleep(100) from t_myisam   |Query |108 | ...继续阅读 (26)

前言很多时候，RDS用户经常会问如何调优RDS MySQL的参数，为了回答这个问题，写一篇blog来进行解释：哪一些参数不能修改，那一些参数可以修改；这些提供修改的参数是不是已经是最佳设置，如何才能利用好这些参数；哪些参数可以改细心的用户在购买RDS的时候都会看到，不同规格能够提供的最大连接数以及内存是不同的，所以这一些产品规格的限制参数：连接数、内存用户是不能够修改的，如果内存或者连接数出现了瓶颈：内存瓶颈：实例会出现OOM，然后导致主备发生切换连接数瓶颈：应用不能新建立连接到数据库则需要进行应用优化、慢SQL优化或者进行弹性升级实例规格来解决。还有一些涉及主备数据安全的参数比如innodb_flush_log_at_trx_commit、sync_binlog、gtid_mode、semi_sync、binlog_format等为了保证主备的数据安全，目前还暂不提供给用户进行修改。除上述的这些参数外，绝大部分的参数都已经由DBA团队和源码团队优化过，用户不需要过多调整线上的参数就可以把数据库比较好的运行起来。但这些参数只是适合大多数的应用场景，个别特殊的场景还是需要个别对待，比如使用了tokudb引擎，这个时候就需要调整tokudb引擎能使用的内存比例(tokudb_buffer_pool_ratio)；又比如我的应用特点本身需要很大的一个锁超时时间，那么则需要调整innodb ...继续阅读 (29)

昨天一同事发现线上系统在并发更新的时候出现了死锁，通过排查定位于update更新使用了两个索引导致，死锁信息如下：*** (1) TRANSACTION:TRANSACTION 29285454235, ACTIVE 0.001 sec fetching rowsmysql tables in use 3, locked 3LOCK WAIT 6 lock struct(s), heap size 1184, 4 row lock(s)MySQL thread id 6641616, OS thread handle 0x2b165c4b1700, query id 28190427937 10.103.180.86 test_ebs Searching rows for updateUPDATE test SET is_deleted = 1 WHERE group_id = 1332577 and test_id = 4580605*** (1) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 132 page no 37122 n bits 352 index `PRIMARY` of table `testdriver`.`test` trx id 29285454235 lock_mode X locks ...继续阅读 (314)

刚刚结束的2015年双11，天猫以912亿的成交量再次打破去年的记录成为一个奇迹，大家可能不知道，这些天猫的订单最后的处理都是放在阿里云聚石塔的机房完成，从2012年开始，淘宝的ISV，商家就开始把他们的订单，CRM后台系统逐渐迁移到云上，最核心的数据库就是存放在RDS中。双11之前用户都会进行大批量的弹性升级，期间有较多用户反馈，在弹性升级后性能出现了大幅度的下降，其中由一个用户有两个RDS，一个RDS进行了弹性升级，另外一个RDS没有出现弹性升级，结果弹性升级后的RDS反而出现了性能下降，这让我们反思不得其解。RDS的弹性升级包括了两部分，一部分是磁盘容量的升级，另一部分是内存容量的升级（内存升级会同时升级数据库的连接数，CPU，IOPS），那么是什么原因导致了性能下降？1.是不是弹性升级后，后端的DB性能提升，前端的流量增加，导致后端DB响应缓慢？通过后端的监控查看，数据库的QPS并没有显著的增加，但是RT却是增加了许多，所以此种情况排除。2.是不是SQL的执行计划发生改变，导致数据库的性能降低？通过监控发现即使是普通的insert 语句也会出现执行缓慢的情况，慢日志出现了较多非常简单的SQL，所以此种情况排除。3.看到有非常简单的SQL也执行缓慢，排查主机是否存在资源瓶颈？通过监控显示，实例所在的物理主机的压力非常的低，不是主机的资源争抢导致的性能瓶颈，所以此种情况排除。4 ...继续阅读 (55)

长期以来有很多的用户咨询如何将RDS的数据同步到本地的数据库环境中，本篇文章以在阿里云的ECS服务器为例来说明如何将RDS的数据同步到本地数据库中。RDS对外提供服务是一个DNS地址+端口3306，这样就屏蔽了RDS后端的主从节点，那么该如何将数据同步到本地？那么我们来看一下RDS的主从架构：应用连接RDS，流量通过SLB指向主从节点的master，所以如果我们连接RDS的账户具有REPLICATION SLAVE, REPLICATION CLIENT的权限，则就可以把主库master的产生的binlog同步到本地数据库中去，实现数据同步。但是这种根据binlog文件和位点来同步RDS的数据到本地的方式非常容易导致同步中断，因为当RDS发生了主备切换（主备切换，重启，跨机迁移），本地数据库所指向RDS的binlog 位点则会发生变化（RDS主库与备库的binlog位点是不一致的），这样就会导致本地数据库与RDS的数据复制同步中断。在RDS 5.6的版本中主备同步使用新复制方式GTID，RDS的主备具有相同的GTID，那么如果主备发生切换，重启或者迁移，主备的GTID是不会发生变化，那么ECSàRDS的同步链路则不会发生中断，所以如果要将RDS的数据同步到本地，则需要将RDS升级到5.6的版本。下面我们将RDS数据同步到本地的一些关键步骤罗列出来：1．在ECS服务器上安装MySQL ...继续阅读 (38)

背景介绍：某客户目前正在将本地的业务系统迁移上云，测试过程中发现后台运营系统，在rds上运行时间明显要比线下PC上自建数据库运行时间要慢1倍，导致客户系统割接延期的风险。用户线下一台PC服务器的性能居然还比顶配的RDS跑的快，这让用户对RDS的性能产生了质疑，需要立刻调查原因。问题分析：通常SQL的执行时间在同等数据量的情况下发生变化主要有以下一些场景，其主要原因是由于优化器生成的执行计划发生了改变，这样则会导致SQL的执行时间发生较大的变化，当然可能变慢，也有可能变快，变慢是我们不想看到的场景：1、  数据库跨平台迁移（PG->MySQL、ORALCE->MySQL）多次遇到数据库从Oracle迁移到MySQL后，由于MySQL的优化器在低版本（5.6以下版本）对子查询的优化较差，导致系统迁移到MySQL后，系统中大量的子查询SQL堆积一直没有返回，导致数据库连接数跑满，数据库的CPU 100%。2、  跨版本升级(MySQL:5.1->5.5、5.5->5.6)也曾经遇到由于数据库在版本（5.5->5.6）升级后原先正常执行的SQL变得奇慢务必，导致整个升级迁移不得不回退，其主要原因高版本（5.6）的优化器策略与低版本（5.5）不同，导致了SQL执行计划发生变化，进而导致了sql的性能急剧下降；问题排查：1．确定优化器版本：先确认用户本地的数据库版 ...继续阅读 (63)

只读实例是目前RDS用户实现数据读写分离的一种常见架构，用户只需要将业务中的读请求分担到只读节点上，就可以缓解主库查询压力，同时也可以把一些OLAP的分析查询放到另外的只读节点上，减小复杂统计查询对主库的冲击，RDS只读节点架构图如下：由于RDS只读节点采用原生的MySQL Binlog复制技术，那么延迟必然会成为他成立之初就会存在的问题。延迟会导致只读节点与主库的数据出现不一致，进而可能造成业务上逻辑的混乱或者数据不正确；另外只读实例延迟同样也会触发binlog堆积，导致只读实例的空间迅速消耗完，这样会导致只读实例被锁定，锁定之后应用则无法完成读操作。最近也收到了很多用户关于只读实例延迟的问题反馈，下面将会分析RDS只读实例出现延迟的几种常见场景，希望能够帮助用户理解和处理只读节点的延迟，更好地使用只读节点：一．只读节点规格过小(10%)二．主库的TPS过高(20%)三．主库的DDL(alter、drop、repair)(40%)四．主库大事务(insert..select)(20%)五．其他（无主键，主机压力）(10%)只读实例延迟场景一：只读实例规格配置过小导致slave延迟，这类延迟场景的出现往往主节点购买的一个非常大规格的配置，而只读节点却购买了一个最小规格的配置（240M内存/150 IOPS）。分析：只读节点的数据为了和主节点保持同步，采用了MySQL原生的binlo ...继续阅读 (60)

经常会收到用户反馈在使用RDS的过程中出现卡慢，闪断地情况，当出现此类问题的时候，首先我们要进行一下测试，看看问题出现在哪一个阶段，RDS给到用户的是一个DNS地址，其实他包括三个阶段：DNS–>VIP–>DB我们可以在本地的应用服务器（VM）上通过简单的ping命令，或者数据库的客户端去不断的连接测试RDS，来获取每次连接RDS的响应时间（RT）。在正常情况下RT应该小于20ms以内，如果超出10ms，则表明了RDS的网络链路出现了异常，这个时候我们就需要去排查一下是在哪里出现了问题：（1）    当DNS链路服务出现问题：当我们测试出DNS的连接比较耗时，而使用vip连接正常的时候，则表明DNS解析比较耗时，此时的问题则出现在了DNS服务上面，这个时候可以尝试换用其它的DNS服务器，或者启用DNS缓存服务，或者暂时在hosts文件中绑定DNS和IP地址，等DNS服务恢复正常后在取消绑定（我们强烈建议在正常情况下不要绑定RDS的DNS和IP地址，或者直接使用IP地址进行访问，因为RDS的IP地址可能会发生改变，绑定ip或者直连ip的方式会导致RDS访问出错）；（2）    当VIP 链路出现问题：当我们测试超出DNS连接比较耗时，同时使用vip连接也比较耗时的时候，则表明RDS的VIP链路出现了异常，这个时候可以提交RDS的工单，让后端的人员进行排查。（3 ...继续阅读 (50)

昨天处理了一则复杂关联SQL的优化，这类SQL的优化往往考虑以下四点：第一.查询所返回的结果集，通常查询返回的结果集很少，是有信心进行优化的；第二.驱动表的选择至关重要，通过查看执行计划，可以看到优化器选择的驱动表,从执行计划中的rows可以大致反映出问题的所在；第三.理清各表之间的关联关系，注意关联字段上是否有合适的索引；第四.使用straight_join关键词来强制表之间的关联顺序，可以方便我们验证某些猜想；SQL:执行时间：mysql> select c.yh_id,-> c.yh_dm,-> c.yh_mc,-> c.mm,-> c.yh_lx,-> a.jg_id,-> a.jg_dm,-> a.jg_mc,-> a.jgxz_dm,-> d.js_dm yh_js-> from a, b, c-> left join d on d.yh_id = c.yh_id-> where a.jg_id = b.jg_id-> and b.yh_id = c.yh_id-> and a.yx_bj = ‘Y’-> and c.sc_bj = ‘N’-> and c.yx_bj = ‘Y’-> and c.sc_bj = ‘N’-> and c.yh_dm = ’00693 ...继续阅读 (32)

背景：RDS Mysql采用的binlog 格式默认为ROW，在Mysql 5.6的版本之前，Mysql每次列的修改（update）都需要记录表中所有列的值。这样就存在一个问题，如果表中包含很多的大字段，表的单行长度就会非常长，这样每次update就会导致大量的 binlog空间生成。针对这个问题，在mysql 5.6中进行了改进，复制支持”row image control” ，只记录修改的列而不是行中所有的列，这对一些包含 BLOGs 字段的数据来说可以节省很大的处理能力，因此此项改进不仅节省了磁盘空间，同时也提升了性能：write event:binlog_row_imageBefore imageAfter imageminimal-All columns where a value was specified, and the autoincrement column if there is onenoblob-All columns where a value was specified, and the autoincrement column if there is one, and all non-blob columnsfull-All columns测试如下：mysql> show global variables like ̵ ...继续阅读 (86)

早上值班同事在旺旺群里面贴了一条非常复杂的SQL，用户从本地迁移到RDS Mysql出现严重性能下降，同样的数据和表结构下，在本地的数据库上只要不到1s的时间，但是在rds上好几分钟都没响应。碰到这类问题需要考虑以下一些因素：a.数据库的版本不同（不同的版本优化器策略不一样，或者异构数据库间的迁移：oracle–>mysql,sqlserver–>mysql），导致sql执行计划不同，最后导致sql执行时间不同；b.数据库的配置不同（不同的内存配置，参数设置–query cache是否打开），导致sql执行时间不同；c.数据库的数据量不同（系统遇到bug，生成了大量的垃圾数据），导致sql执行时间不同；根据以上线索，用户是刚刚从线下迁移到RDS的，所以数据量和表结构是相同的；RDS配置为：2400M内存，1200IOPS，本地是笔记本电脑：4000M的内存，5600转的笔记本电脑，所以数据库配置来说区别并不大；所以就剩下数据库版本了，RDS的版本是Mysql 5.5，而用户使用的数据库版本是5.6，所以问题很可能出现在这里，mysql 5.6和5.5在优化器上最大的改进就是对子查询的优化改进：a.5.0、5.1、5.5对子查询处理：不会将子查询的结果集计算出来用作与其他表做join，所以很有可能outer 表每扫描一条数据，子查询都会被重新执行一 ...继续阅读 (46)

上一篇文章中,我们介绍了如何快速的把本地自建的数据库迁移入云,那是不是把数据库迁移到RDS后，用户就什么都不需要做了？比如RDS帮你的数据库做到了高可用，在主库出现down机后能够快速切换到备库，立刻恢复应用；每天会定时的备份数据和日志，如果出现误操作能够帮你恢复到任意时间点；如果担心黑客攻击或者sql注入漏洞，RDS能够帮助你进行sql注入的拦截；当数据库使用中出现bug时，后端有专业的源码和DBA团队帮助用户实例打上patch，让用户无后顾之忧；当实例的性能出现瓶颈的时候，可以进行快速的弹性升级，保证服务的正常运行等等。可以看到RDS已经具备相当丰富的自动化数据库运维的功能，用户不用太关心后端数据库的运维，以前这些非常专业的DBA工作完完全全可以交由RDS系统来完成，那么还需要用户做什么，是不是不需要用户干预了？答案是需要的，在日常的工单问题发现：一． 经常会发现由于自己的开发人员误操作导致用户数据被误删除，虽然RDS支持恢复到任意时间点，但毕竟需要时间去恢复，会造成对用户的影响；所以线上的操作务必谨慎，必须在测试环境中完全验证后才能到线上执行，同时需要必要的数据备份；二．开发人员发布了一个新功能，但是新功能中的一条sql语句没有添加索引，导致了全表扫描，RDS的CPU，IO达到100%，影响了整个应用的响应时间；所以新发布的任何sql都必须进过严格的审核，添加上必要的索引；三 ...继续阅读 (42)

在上一篇中大致介绍RDS的一些基本参数,包括数据库类型，版本，存储空间，规格：内存，连接数，io，地域等基本含义，本篇中将介绍如何快速平稳的迁入RDS。用户在购买完RDS后，接下来就可以开始往RDS迁入数据了。在RDS刚刚对外提供服务的时候，用户只能通过将自己的数据库dump成为sql文件，然后再将sql文件source到RDS中去：数据迁移至RDS-MySQL之使用MySQLdump工具，数据迁移至RDS-SQLserver之利用SQL Server客户端工具，这两种方法是最简单的方法，但是局限性也非常的多：.用户的数据库太大了，逻辑sql导入的方式速度太慢了，严重影响停机时间；.在导入的过程中报错很多，或者导入一半的过程中中断了，需要重新来过；.在迁入RDS过程中，希望我的数据库还能能正常提供服务；大量的用户入云全部堵在迁移数据上面，用户与RDS的缘分就差么这临门一脚。工欲善必先利其器，为了更好的帮助用户入云,RDS对现有的用户入云迁移方式进行改进，帮助用户快速稳定迁移入云，分别为用户提供了mysql和sqlserver两套改良迁移工具:.mysql迁移工具支持在线迁移，用户可以不中断业务的情况下把数据迁移到RDS中来;.sqlserver的迁移工具采用物理备份的方法，将用户的物理备份上传到FTP中后还原到RDS，提升迁移的速度;这两套工具目前都已经集成到了RDS的控制台中，可 ...继续阅读 (53)

我该如何选择RDS？我要购买多大规格的RDS？RDS的连接数，iops指的是什么？上诉这些问题相信是每一个RDS用户在开始使用的时候都会有这样的疑问。首先我们要了解一下RDS的组成包括哪一些，从阿里云官网的购买页面中我们可以看到RDS包括了以下参数：数据库类型，版本，存储空间，规格：内存+连接数+io，地域，那我们就一个个来分析一下：一.数据库的类型：RDS目前支持的数据库类型有两种：mysql，sqlserver，为什么这里要特别提出来讲一讲？原因有以下两个方面：a.由于受到sqlserver和windows license的影响，sqlserver价格会比mysql高出近50%，一个2G Mem+50GB Disk的Mysql一年的价格是：4480 RMB；一个2G Mem+50GB Disk的Sqlserver一年的价格是：6420 RMB;b.sqlserver处于闭源状态，在出现异常疑难问题排查的时候，往往需要借助微软官方的帮助，同时RDS如果想在sqlserver上面定制出一些自己特色的功能时候，往往其封闭的协议让RDS望而退步；相对于mysql的开源而言，RDS依托了阿里强大的mysql内核开发和运维经验，能够很好的定制出一些RDS自己的特色功能，在出现疑难问题上能够迅速的进行debug排查。二.数据库的版本：RDS mysql目前支持5.5和5.1两个版本，sqls ...继续阅读 (76)

用户的ibdata1文件持续增加：Innodb的表有两种存放方式：第一种共享表空间方式：所有表的索引，数据统一存放在一个共享表空间中，这样会导致共享表空间的空间迅速增长，同时空间回收困难；第二种独占表空间方式：就是RDS目前采用 的，也就是一张表一个表空间，表中的索引和数据存放在自己独立的表空间中，空间能够比较容易的回收；无论是独占还是共享表空间，innodb都会有系统共享表空间（ibdata1），该系统表空间主要用于存储数据字典，undo entry，insert buffer，doublewrite buffer，该系统表空间的增加通常的原因有如下：a.长时间没有提交事务，同时数据库中有大量的更新，插入，删除 ，导致innodb创建大量的undo来维护一致性读：可以通过show engine innodb status\G查看active的事务：SHOW ENGINE INNODB STATUS\G—TRANSACTION 36E, ACTIVE 1256288 secMySQL thread id 42, OS thread handle 0x7f8baaccc700, query id 7900290 localhost rootshow engine innodb statusTrx read view will not see trx with id >= ...继续阅读 (68)

问题：xxx@3023 14:51:26>insert into test_tmp_log_node_10445__01 select * from test;ERROR 1062 (23000): Duplicate entry ‘taobao|维西v’ for key ‘idx_nodetemp_10445_01′查看表结构：CREATE TABLE `test` (`user_id` varchar(64) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL COMMENT ‘主键。客户全局统一ID，由客户统一ID生成规则生成’,`control_group_type` int(2) NOT NULL DEFAULT ’0′) ENGINE=InnoDB DEFAULT CHARSET=utf8;CREATE TABLE `test_tmp_log_node_10445__01` (`user_id` varchar(64) DEFAULT NULL,`control_group_type` tinyint(4) DEFAULT NULL,UNIQUE KEY `idx_nodetemp_10445_01` (`user_id`)) ENGIN ...继续阅读 (34)