ANBOB™

在 MySQL 中，character_set 配置用于指定数据库、表、列或连接的字符集。字符集决定了如何存储和检索字符数据，例如 UTF-8、latin1 等。MySQL 中有八个与 character_set 相关的配置选项，如下所示。如果不仔细阅读MySQL字符集文档，可能很难知道这些配置选项的用途。此外，对于某些选项，除非进行进一步测试，否则很难知道 MySQL 如何使用它们。

最近有个客户查看MySQL主从同步时，提示ERROR 2027(HY000):Malformed packet错误，存在slave连接失败的现象，后分析是因为该MySQL配置了oracle goldengate，以replication slave的方式抽取，仅记录提醒再次遇到该问题。

今天一客户的TiDB数据库环境业务查询报错，单条SQL的执行内存上限，提示如下：
Your query has been cancelled due to exceeding the allowed memory limit for a single SQL query. Please try narrowing your query scope or increase the tidb_mem_quota_query limit and try again

在十年前简单测试过oracle 9i 的加密解密用法之dbms_obfuscation_toolkit(二)，其中有md5单向加密， 最近在oracle迁移到opengauss项目中用到了md5， 这里简单记录替换方案，在pg或og中直接就有md5 function. 在mysql及Mysql系的产品和ocenabse, 达梦一样存在该函数md5。

很久以前记录过一篇 Oracle Estimate of the duration of a rollback operation (估算rollback事务回滚剩余时间) ，oracle的大事务cancel或kill后的回滚操作，rollback所花费的时间通常比原来的操作还要长，而且在回滚完成前有可能会堵塞其它事务，在PostgreSQL中因为没有使用undo而是多版本，所以忽略rollback的时间，这是PG的强项，但是在MySQL中和oracle一样同样存在回滚问题，这里简单记录如何估算MySQL中的事务回滚时间。

最近，我注意到一位朋友在处理一个以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 块的访问，我们对比一下几款数据库在该方面的能力。