ITPub博客

01 背景select into outfile无论对于开发或DBA来说，都是一个爱不释手的导出数据的方式。相比mysqldump，它能够对需要导出的字段做限制，很好的满足了某些不需要导出主键字段的场景或分库分表的环境下数据的重新导入。且与load data infile配合起来，无疑是一款数据导入导出的利器。最近，开发小伙伴在测试环境使用select into file进行数据导出时，碰到了一个

在Part 1中我们了解了两种获取执行计划的方式，第一种是优化器预测它将会怎么执行，通过以下方法查询获取：explain plan for {sql statement} select * from table(dbms_xplan.display);第二种是优化器在我们执行语句后真正的执行路径，通过以下方法查询获取：set&

看懂执行计划是作为处理数据库性能问题的必备技能之一，接下来一系列的文章我会告诉你怎么去做。我们会从一些文章开始讨论几种获取执行计划的方法，并且评估不同来源的执行计划最适合哪种场景。完成上述的内容后我们会继续深入解释简单执行计划的基础，之后会介绍一个用来解释大部分执行计划的规则-需要小心使用该规则。同时也会重点说明因为优化器改写我们的SQL导致执行计划与预期的不符的情况。一些规则外的异常不可避免，所

在本系列的前一期文章中，我制作了一些图，突出显示了按表扫描执行大量删除操作和按索引范围扫描执行大量删除之间的主要区别。根据所涉及的数据模式，选择正确的策略可能对随机I/Os的数量、生成的undo的数量和排序所需的CPU数量产生显著影响——所有这些都可能影响执行删除所需的时间。然而，这个简单的演示跟生产环境当中相比，生产环境当中这个情况更为复杂。所以，如果你面临着一项艰巨的任务，你需要仔细考虑如何对

在本系列的上一部分中，我们研究了在大数据删除表和索引和案例。在这一部分中，我们将继续讨论不同案例所隐含的工作量，然后考虑删除策略，或者需要制定减少工作量的策略。基本开销部分除了时间本身，我们还要关注其它三个指标，即大数据删除的过程中：生成的undo和生成的redo以及发生的I/ O量。这些因素并不是相互独立的，这在优化删除的一般性讨论中引入了很多复杂性，并且删除操作本身可能会影响同时运行的其他会话

在这个简短系列的第1部分中，我提供了两个场景的非正式描述，在这些场景中，我们可以从表中进行大规模删除。没有一个具体的例子,很难想象删除数据的性质和可用的访问路径会产生大数据量删除操作对系统的性能影响,所以我要把大部分的时间花在本文讨论的两个测试生成的数据集。这篇文章似乎有点长但相当多的空间会被表格占用。简单的数据集随着硬件的能力和规模的不断增长，我们越来越难以就“大表”或“大规模删除”的含义达成一

前言我们在日常维护数据库的时候，如果遇到慢语句查询的时候，我们一般会怎么做？执行EXPLAIN去查看它的执行计划？ 是的。我们经常会这么做，然后看到执行计划展示给我们的一些信息，告诉我们MySQL是如何执行语句的。BUT，执行计划往往只给我们带来了最基础的分析信息，比如是否有使用索引，还有一些其他供我们分析的信息，比如使用了临时表、排序等等。我们能从这些信息里面找一些优化点，这样就足够了吗？看看这

toc或许某些人会说MySQL Low，而且乐此不疲，不过，我完全也可以说某些人压根就不会用MySQL，万事万物都具有两面性的，最终结果的好坏还得看是谁在用、怎么用。关于这个问题的争论，相信大家都喜闻乐见了，尤其是数据库界的"郭德纲"的言论尤其精彩，没事听听数据库界的"郭德纲"讲讲故事、讲讲段子，也是一件蛮有意思的事情。说回到大事务，大家或多或少都不太喜欢它

MySQL 执行DDL语句 hang住了怎么办? 不要慌，先点支烟，听我娓娓道来！前两天，早上7点多的时候，抓起手机忽然看到了圈内的一则DDL语句 hang住的案例，阅读到文末，发现文中留有一些疑问（当然，文章是7月份的，现在或许作者已经解决了这些疑问），于是一咕噜从床上爬起来，按照文中的复现方法操作了一遍（复现方法见文末），然后，按照自己的思路解决了该疑问，现在将整个过程整理出来分享给大家。环境

1、故障现象某客户反馈，在利用binlog日志的解析内容做基于时间点的恢复时，出现hang死（超过12小时那种），恢复过程无法继续，而且100%重现基于时间点恢复的实现方式为：使用mysqlbinlog命令指定一个结束时间点，解析binlog并使用管道直接导入数据库中执行（例如：mysqlbinlog binlog_file | mysql -uroot -pxx）对此，我们收集了最基本的一些环境

本文主要介绍Prometheus，从他的来源，架构以及一个具体的例子等方面来说明，以及沃趣围绕Prometheus做了哪些工作。

前两天，无意间看到了林晓斌(丁奇)的一篇文章（详见文末参考链接的第一个），突发好奇心，想从MySQL暴露出来的一些信息上着手，看看能不能直观地看到MySQL 5.7的并行复制到底可以同时执行多少个binlog group(last_committed)的事务，经过一番折腾，将验证过程整理成这篇文章分享给大家。测试验证过程中，使用了两个MySQL版本，如下：MySQL 5.7.22：sysbench

Oracle数据库环境中隔离级别为readcommitted，每个事务都只能看到其他事务已提交的更改和自己未提交的更改。所有关于CR块的统计都可以通过x$bh视图查看。read-commited隔离级别下的有两种可能性：语句级别：查询结果与查询的开始一致（snap_scn=当前SCN）。事务级别：查

Oracle RAC CR Server Part One

在上一期《数据库对象信息记录表|全方位认识 mysql 系统库》中，我们详细介绍了mysql系统库中的元数据记录表，本期我们将为大家带来系列第四篇《统计信息记录表|全方位认识 mysql 系统库》，下面请跟随我们一起开始 mysql 系统库的系统学习之旅吧。

我们为什么要删除大量的数据？我们是否知道在删除操作完成后我们又需要如何验证我们是否到达最终目标？我们可以使用哪些方法来最小化的执行删除所带来的影响以及删除完成之后我们还需要做什么才能达到最终的目标？

我们为什么要删除大量的数据？我们是否知道在删除操作完成后我们又需要如何验证我们是否到达最终目标？我们可以使用哪些方法来最小化的执行删除所带来的影响以及删除完成之后我们还需要做什么才能达到最终的目标？

本文基于公司产品需求，对比研究5.7版本下binlog server备份binlog的功能，以及该工具的优缺点。

前面的章节我们介绍了Oracle为实现Cache Fusion引入的各种改变和新的概念。本节我们从RAC环境中可能发生的场景对Oracle Cache Fusion的实现进行更近一步的探讨。

前面的章节我们介绍了Oracle为实现Cache Fusion引入的各种改变和新的概念。本节我们从RAC环境中可能发生的场景对Oracle Cache Fusion的实现进行更近一步的探讨。