ANBOB™

最近，我注意到一位朋友在处理一个以G字开头的MySQL系国产数据库时遇到了一些问题。具体来说，该数据库占用了超过1TB的临时文件，导致文件系统告警，之前kill session并且未能释放。这是由于在杀掉dbproxy上的session后，db node上的session仍然存在。这样的情况可能是非原生分布式数据库的一个风险点，因为每个data node都是一个独立的MySQL实例。最终，我们通过登录到data node并手动kill session解决了问题。我在另一款国产MySQL系分布式数据库GoldenDB上进行了类似的模拟测试，仅记录处理方法。

在MySQL 5.6或从5.6 升级到8.0后有可能会遇到ERROR 1071 (42000):Specified key was too long; max key length is 767 bytes 报错，提示是遇到了索引KEY的最大上限767 字节。在本文中，我将解释此错误发生的原因以及如何解决它。

上周，Percona 发布了一篇警告博客，提醒用户<不要升级到 MySQL 8.0.37 之后的任何版本>。然而，现在访问 MySQL 官方下载页面，依然可以在主推的下拉列表中看到这些版本。
Percona 在文章中提到，Jean-François Gagné 在 bug.mysql.com 上报告了一个编号为 #115517 的 bug。不幸的是，这个 bug 目前处于私密状态。简而言之，如果您创建大量表（例如 10000 个），MySQL 守护进程在重新启动时会崩溃。当然，也有人认为这是危言耸听，因为单个数据库实例中有超过1万张表的用户可能不足0.0000001%。

Oracle 数据库在在线维护操作方面引入了大量特性，旨在实现日常维护和升级时无需停机。相比之下，MySQL 在这方面的表现稍逊一筹。作为 Oracle 的 DBA 是一件很幸福的事情，因为日常的分区维护、发现性能问题时的紧急创建索引等操作都可以在线完成。而 MySQL 虽然也宣称支持 DDL，但这是真的吗？

我们有一个 GoldenDB 的客户要求以后所有的 DDL 操作只能在停所有业务的情况下执行。对于拥有大量数据库实例且需要频繁进行 DDL 维护的情况，请问你能提供多少停机时间？

数据库存放着组织拥有的最重要的资产之一——数据。保持数据安全和不受破坏是关键任务。对于大多数应用程序来说，停机比数据丢失或损坏更痛苦。DBA的核心职责包括数据库的备份恢复，到了关键时刻非常考验方案的有效性。在MySQL开源数据库也存在一些备份工具，但存在一些差异，备份应根据恢复需求进行规划, 这里简单整理。

The maximum size of large objects (LOBs) in Oracle, PostgreSQL, and MySQL varies depending on the type of LOB and the database system. Here are the details for each database:

MySQL事务隔离级别默认的Repeatable Reade 下有Gap Lock问题，在更低的隔离级别下，如读已提交（Read Committed）或读未提交（Read Uncommitted），Gap Lock不会被使用，在READ-COMMITTED下同样存在类似“Gap Lock”的问题，如果Oracle 数据库向基于MySQL innodb的数据库迁移后，不知是否会出现原有应用经常行锁等待的现象，等待innodb_lock_wait_timeout参数配置的时间后报错, 而oracle lock是在行头(row header)上，MySQL这种导致锁定记录增加的现象，让从事oracle DBA转型的无法理解

前几日一客户问我在oracle执行unix_timestamp函数报错，心想这不是MySQL的函数吗？难道oracle引入了？找了一圈到oracle 23ai也没有自带该函数，可以自定义函数实现， 在去年的一个oracle迁移到PostgreSQL系数据库里，有套业务库大量使用epochs做为datetime，这里简单记录在oracle, mysql ,postgresql中如何做unix epoch到datetime的转换.

最近一客户的应用日志随机会出现一些数据库源访问错误，中间件使用Caucho的连接池，数据库为MySQL 5.7主从，前端有HAproxy, 应用server多个，报错也不是持续性，再次重试可能会就正常，错误日志DataAccessException: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago.

Oracle数据库有dataguard主从，MySQL有主从或MGR，Goldengate同步支持从前两种数据库做数据抽取，但是在主从切换以后需要在Goldengate做相应的修改。这里记录一下MySQL因master 需要停机维护时，OGG主动切换到slave的方法。

事务隔离级别是数据库事务处理的基础，ACID 中的 “I”，即 Isolation，指的就是事务的隔离性。ANSI/ISO SQL 标准定义了4 种事务隔离级别，对于相同的事务，采用不同的隔离级别分别有不同的结果。这些隔离级别是根据3 个“现象”定义的，

之前曾经在《oracle add column xx default value 增强(二)》记录过，在日常运维中增加column是常见的操作，对于大表增加列时是否会导致回写表还是只修改数据字典影响DDL的执行时间和停机窗口长短。之前也在《“alter table ” modify column in Oracle、MySQL、PostGreSQL(数据库比较系列十三)》记录修改column时不同库的表现， 这里简单记录测试一下当前主流的几个库对于add column的现象。

前几天看到有OB用户留言，提到OceanBase很可能是出于对他们需求的考虑，而应用中以前对ORACLE报错的依赖。这表明现在数据库厂家在满足各种甲方要求时也颇为无奈，在应用的兼容性上做了种种让步。就对于会话1事务中，会话2 select for update nowait相同的报错场景，我简单测试一下在其它国产库上是否还不如Oceanbase. 为了方便横向对比，这里我再简单的附上ORACLE 与OB的报错。

在关系数据库中两表关联在oracle中使用IN( subquery)的语法很常见， 但kevin发现在MySQL中subquery使用MAX聚合参数时，会导致主查询Full scan而无法使用索引范围扫描, 当遇到大表时可能性能下降明显 ，测试发现有的库使用子查询做为驱动表，有的是使用filter从主查询过滤。下面简单测试。

在关系数据库中常见的一种需求统计表的记录的最大值或最小值，SQL中使用max min，为了最佳效率通常希望可以在列上创建索引，减少表段的IO量，如果可以可以使用更佳的执行计划如直接访问索引的头和尾（btree index的有序结构），减少index 块的访问，我们对比一下几款数据库在该方面的能力。

国产库在承接Oracle替换方面做了大量的兼容性，如果仅实现了语法兼容，没有相同的语义，这恐怕比不兼容还糟糕，比如原来的oracle的应用迁移到国产库后执行不报错，但却有可能和oracle得到完全不一样的结果。今天我们以万里开源的GreatDB中的sysdate为例， 对最近同事遇到这个案例简单分享。

MySQL架构中经常会遇到和keepalived、HAProxy中间件的组合，解决MySQL的高可用与负载均衡的需求， 但是会给数据库配置带来复杂性。如果没有把这些组件与MySQL级联配置，可能会出现一些意向不到的问题，了解HaProxy就变的重要，近期一个客户在这样的环境做压力测试时，MySQL数据库的max_connections最大链接数已调整到10000, 但一应用反馈链接报错，从数据库上看链接最大也就在2000左右，并且MySQL日志未出现报错，

在企业级运维中，应用程序用户和维护用户通常不建议复用，分别能过权限控制给维护人员修改应用对象的权限， 但是对于存储过程在MySQL中授权相对较麻烦，没有像oracle数据库中的alter any procedure的系统权限。 比如当user1修改user2创建的存储过程时，在DDL中带有“DEFINER=”其他用户时会报错如下:
ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER or SET_USER_ID privilege(s) for this operation

谈起安全防护方面，数据库用户可能会遭遇暴力破解的风险，在oracle数据库中有profile配置如配置尝试次数据等，同时在11g起引入了密码延迟认证，增加密码失败后尝试的时长，也带来了新的问题如较高的libarary cache lock,MySQL中的解决方案可以安装connection_control插件库，在MySQL 8.0 中引入，并向后移植到 MySQL 5.7 和 MySQL 5.6，但同样它也带了新的问题。

当两张大表做join访问时，我们希望优化器使用hash join的方式连接提高查询性能，但是在主流的oracle,mysql,postgresql或openGauss中变现稍有差异，所以在数据库替换时需要注意，简单记录一下对于equi join(=)，non-equi-join(<>),Semijoin(exists), Antijoin(not exists/in), outer join(left/right join)时的不同表现。