ANBOB™

在关系数据库中常见的一种需求统计表的记录的最大值或最小值，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)时的不同表现。

对于一个连续7*24小时的业务，如果session 1正在select查询一张大表，而另一个session尝试drop 相同的表，会发生什么？对于最流行的MVCC数据库oracle,mysql,postgreql需要对比，因为drop不只是字典表更新标记，还需要回收物理空间。在这几个数据库中的表现一样吗？Oceanbase和goldenDB及GreatDB的表现.

PostgreSQL系(openGASUSS)数据库中的所有索引都是二级索引, 数据表段（ heap）和索引段（index）分别存储，通常对于多列表的SQL只返回或where中仅少量的列时，希望可以只从索引中检索，而不用再从索引回表返回数据（本篇不考虑可见性）提高查询效率，像在oracle中有index full scan和index fast full scan的执行计划，在Postgresql中也支持Btree index的indexonlyscan， MySQL中同样支持，但发现PostGreSQL默认配置的SQL优化器通常判断索引的cost大于表扫描，导致仅查询索引列也未使用索引

近日因为一个MySQL备份使用XtraBackup失败的问题，让我认识了一下MySQL的DDL中ALGORITHM=INSTANT算法，发现该问题引起的风险并不小这里整理一下，Oracle其实也一样，在不同的版本中有可能引入一些新特性同时，也可能引入一些风险bug,

MySQL 中也有像oracle v$sysstat简化的实时监控InnoDB表内部计数器， MySQL 8.0.31 最新版有310多个计数器， 使用show engine innodb status可以查看，但可读性并不好，有些版本显示内存总扩展为0错误。这个问题影响>= 8.0.27.

之前在如何在Oracle 19c expdp/impdp 脚本中不使用密码？ 一文记录过在Oracle备份的shell脚本中不配置明文密码，MySQL同样可以使用mysql_config_editor工具生成存储加密登陆的方式，使用的模糊处理可防止密码以明文形式显示，并提供 通过防止无意中泄露密码来衡量安全性

前几天有套MySQL业务上线，开发提供的那表脚本中默认表级字符集为utf8bm3, 印像是utf8mb4在MySQL8为默认首选字符集，所以针对这块做个小功课，utf8bm3和utfbm4在MySQL8中我们应该选哪个字符集？会有什么影响？

‘alter table’ DDL操作后期运维时比较常规的操作，但在oracle,MySQL，PostGreSQL中行为并不相同，Oracle还是三者中代价最低的，但是在Oracle DBA转向其它数据库运维时，以O的经验维护像MySQL、PostGreSQL时修改列的小动作可能会出现故障，比如空间耗尽、持续时间长、锁、执行计划变等现象。这篇分别测试一下三个数据库在ALTER TABLE modify column上的影响。

ANSI/ISO SQL 标准定义了4 种事务隔离级别，对于相同的事务，采用不同的隔离级别分别有不同的结果。这些隔离级别是根据3 个“现象”定义的,在Oracle 中READ COMMITTED 则有得到读一致查询所需的所有属性，在其他数据库中的读READ COMMITTED 可能会有不同的答案， 最近有个客户在测试migrate oracle to postgreSQL测试发现一个批处理的结果并非一致，

在有些程序员开发习惯中，喜欢为了应用代码的简洁或复用，而在数据库创建一个复杂关连查询的VIEW，甚至是VIEW套VIEW嵌套使用， 这里就有个问题如果上线后如发现依赖的表字段类型或长度不足时，修复一个view依赖的table列时发现在oracle、mysql、postgresql（本篇等同pg）中有不同的表现， 尤其是使用postgresql的用户需要格外注意， 因为pg 不允许直接修改

在创建表时，如果相同的列类型，不同表列的顺序是否会影响数据库占用空间大小？使用oracle、mysql或postgresql是不是相同的表现呢？ 不是的Postgresql近期发现空间使用会因为columns的顺序而占用不同的大小，当然也和实际的数据有关，简单的测试。

数据库运行过程中在错误日志或SQL运行时报错难以避免，oracle预制了好多错误代码，也有不确定性的会在ora-600 700 7445中， 所以Oracle DBA通常是先看ORA-xxxxx编号的错误，确认是否与数据库层相关，oracle database提供了一个命令行工具oerr工具查看错误代码的message和一些很友善action简单的处理建议。 好奇其它两个主流开源数据库有没有相同的工具？这里简单的记录

一套oracle 12c physical casecade dataguard 多租户环境，a–>b –>c， 用户在登录B standby数据库时间隔性提示ora-1017密码错误， 并且发现只是其中一个Pdb 存在这样的问题，如连续多次登录中其中有部分登录成功。

数据库维护过程中难免会遇到一些不正常的SQL或会话进程正在占用系统大量资源，临时需要终止查询或kill会话，在Oracle, MySQL, Postgresql数据库中不同的操作。

像UNIX的PS1环境变量可以改变shell操作提示符， 在日常工作环境中可以提升一些效率可以防止一些误操作， 很多年前在看tom关于在练习oracle操作前的一些环境配置像login.sql， 还可以显示当前的用户或数据库名很是欣喜， 下面记录Oracle , MySQL, PostgreSQL三个主流数据库改变命令行提示符的方法。