<meta property="og:updated_time" content="2019-07-28T03:29:41.634Z">

<h3 id="具体分析看mysql实战45讲的21讲"><a href="#具体分析看mysql实战45讲的21讲" class="headerlink" title="具体分析看mysql实战45讲的21讲"></a>具体分析看mysql实战45讲的21讲</h3>

<meta property="og:updated_time" content="2019-07-28T03:29:27.817Z">

background: #20cb4f;

<h3 id="背景"><a href="#背景" class="headerlink" title="背景"></a>背景</h3><p>因为业务的需求, 公司的一张大表需要添加字段, 先看了下表的大小, 行数到是还行, 才几十万, 但是, 因为有大字段的原因, 这个表有几十个G, 因此, 考验的时候就来了, 找了个业务不繁忙的时候, 果断添加了字段, 可是这个过程中, ddl执行了快一个半小时, 然后磁盘的iops快要爆炸, 因为业务低锋期, 倒也还没造成什么大影响, 但难免对大表加字段产生了深深的恐惧;<br>于是我们来探究下大表加字段究竟做了什么动作;</p>

<p>Online DDL实现:<br>其实实质也是包含了copy和inplace的方式, 对于不支持online形式的, 也是直接采用了copy的方式;<br>online DDL主要包含了3个阶段;<br>1.Prepare阶段:</p>

<li>创建新的临时frm文件;</li>

<li>持有EXCLUSIVE-MDL锁, 禁止读写;</li>

<li>根据alter方式, 确定执行方式:(copy, online-rebuild, online-norebuild)</li>

<li>更新数据字段内存对象;</li>

<li>分配row_log对象记录增量;</li>

<li>生成新的临时ibd文件;</li>

<p>2.ddl执行阶段:</p>

<li>降级EXCLUSIVE-MDL锁, 允许读写;</li>

<li>扫描old_table的聚集索引每一条记录rec;</li>

<li>遍历新表的聚簇索引和二级索引, 逐一处理;</li>

<li>根据rec构造对于的索引项;</li>

<li>将构造索引项插入sort_buffer块;</li>

<li>将sort_buffer块插入新的索引;</li>

<li>处理ddl执行过程中产生的增量(仅rebuild类型需要)</li>

<p>3.commit阶段:</p>

<li>升级到EXCLUSIVE-MDL锁, 禁止读写;</li>

<li>重做最后row_log中最后一部分增量;</li>

<li>更新innodb的数据字典表;</li>

<li>提交事务(刷事务的redo日志)</li>

<li>修改统计信息</li>

<li>rename临时idb文件, frm文件;</li>

<li>变更完成;</li>

<h3 id="常用的ddl操作表"><a href="#常用的ddl操作表" class="headerlink" title="常用的ddl操作表"></a>常用的ddl操作表</h3><table>

<th>操作</th>

<th>并发DML</th>

<th>算法</th>

<th>备注</th>

<td>添加/删除索引</td>

<td>YES</td>

<td>online(no-rebuild)</td>

<td>全文索引不支持(聚簇)</td>

<td>修改default值 修改列名 修改自增列值 添加/删除外键约束</td>

<td>YES</td>

<td>Noting</td>

<td>仅需要修改元数据</td>

<td>添加/删除列 交换列顺序 修改NULL/NOT NULL 修改ROW-FORMAT 添加/修改PK Optimize table</td>

<td>YES</td>

<td>online(rebuild)</td>

<td>由于记录格式改变, 需要重建表</td>

<td>修改列类型 删除PK 转换字符集 添加全文索引</td>

<td>NO</td>

<td>Copy</td>

<td>需要锁表, 不支持online</td>

<h3 id="online-ddl总结"><a href="#online-ddl总结" class="headerlink" title="online ddl总结"></a>online ddl总结</h3><p>1.实际上的优化就是对dml锁的细化, 只在某些关键部位进行全锁, 而不是整个阶段;<br>2.然后运行并发读写后, 后面就需要留有一部分时间做增量的合并操作;<br>3.若ddl异常, 可能会导致无法再次添加ddl的动作, 那是因为整个过程并不是一个原子操作, 而是复合式的, 所有ddl异常时, 需要清除残留的数据;</p>

<h3 id="最终加表字段的注意事项"><a href="#最终加表字段的注意事项" class="headerlink" title="最终加表字段的注意事项"></a>最终加表字段的注意事项</h3><p>1.尽量选择流量小的业务时间段;<br>2.如果可以的话, 进行主从切换来加字段最好;<br>3.执行时,先看一下有无未提交的事务, 注意查看事务information_schema.innodb_trx表;<br>4.加了之后, 随时关注下服务器日志情况;<br>出现问题的, 可能会出现这样的sql会话;<br><figure class="highlight plain"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">waiting for table metadata lock</span><br></pre></td></tr></table></figure></p>

<h3 id="锁的种类"><a href="#锁的种类" class="headerlink" title="锁的种类"></a>锁的种类</h3><p>1.行锁;(InnoDb引擎有)</p>

<h3 id="具体分析看mysql实战45讲的21讲"><a href="#具体分析看mysql实战45讲的21讲" class="headerlink" title="具体分析看mysql实战45讲的21讲"></a>具体分析看mysql实战45讲的21讲</h3>