-
编辑 删除
MySQL 精度扩展时候的DDL阻塞对比Oracle
曾经我分析过在MySQL数据库上字段扩位是否只是快速更新元数据的那次是因为是在实际工作中意外遇到的问题，所以做了实验得出在64以下改变没有问题。64以上的改变也没有问题。但是当从小于64的改到64以上时候则会发生问题。（不是简单的改元数据）当时这个结论使得我们在日常变更中可以判断影响面。最近有一个新的场景，精度变更出于对上次的判断，我觉得这里有一些不确定性。十有八九会有要注意的问题。事实证明我判断
-
编辑 删除
MySQL的replace使用分析
这个我之前没有研究过，看名字就是替换。 因为我实在想不出我现在业务场景中会用到它。没想到还有开发人员居然去使用。从名字解析可能类似Oracle的merge into update的做法先实验看看实际效果为了观察binlog，新刷新一个。mysql> truncate table t1; Query OK, 0 rows
-
编辑 删除
一个在使用方法上的低级错误（MySQL场景）
首先申明这个技术含量不高初始化问题数据。注意这里的t代表时间，数据类型是字符串。为什么用字符串来表示时间？那这就是问题所在。当初创建的人不懂。这个回答不知道满意吗？mysql> create table t1 (id int,t varchar(20)); Query OK, 0 rows
-
编辑 删除
一次DDL引发的数据库异常关闭
接到别人求助：有个数据库重启了看看是什么原因？我现在一般都是处理应用开发问题，很少遇到数据库重启的问题了。日志发过来，我一看是MySQL。我已经多年没有遇到过这种了。最后一次处理这样的问题还是2019年。当时系统是由于应用程序的问题也遇到过DDL时候数据库实例关闭。不过有些系统哪怕没有DDL也会造成数据库实例关闭。有人说是bug，我个人不这么认为。哪有那么多bug？我认为重现的才能说是bug，比如
-
编辑 删除
当MySQL的int不够用了
关于int的长度很多时候看到int(8)这样的定义，其实这是工具导出的不专业。int是范围，不是长度。在开发有了共识（知道这个长度不算数，要看范围）以后，上来就是所有的类型都是bigint。int的范围int的取值范围是TINYINT：占用1个字节（8位），取值范围是-128到127（有符号），或者0到255（无符号）。SMALLINT：占用2个字节（16位），取值范围是-32,768到32,76
-
编辑 删除
组合索引作用
很简单的道理但是日常开发人员还有很多不理解以MySQL为例，其他数据库也是一样。样品数据如下：mysql> select * from x;±-----±-----±-----+| id | a | b |±-----±-----±-----+| 1 | 1 | 1 || 2 | 1 | 2 || 3 | 1 | 3 || 4 | 1 | 4 || 5 | 1 | 5 || 6 | 2 |
-
编辑 删除
in null和not in null
这是A和X两个表的样本数据mysql> select * from x;±-----±-----±-----+| id | a | c |±-----±-----±-----+| 1 | 1 | 1 || 2 | 2 | 2 || 3 | 3 | 3 || 4 | 4 | 4 || 5 | 5 | 5 || 6 | 6 | 6 || 7 | 7 | 7 || 8 | 8 | 8 || 9 |
-
编辑 删除
数据库的基础的exists
很多基础的东西可以拿来细说一下：假设X和Y两个表如下：mysql> select * from x;+----+------+| id | a |+----+------+| 1 | 1 || 2 | 2 || 3 | 3 || 4 |&nb
-
编辑 删除
一个简单的方式看看MySQL的锁
突然发现半个月没写了。最近事情太多了。在日常工作的处理问题的过程中，我发现了一个简单的论证锁的问题，以前我讲的有点复杂，看来应该去改改之前的讲法了。首先构造一个无主键无索引的表。并且初始化5条数据。场景A： RR隔离级别下， 无where条件的update， 这种的update操作由于没有带where条件，我说是对全表进行更新应该没有争议吧？那么全表更新的操作说是对每一行发生锁定应该没有争议吧。可
-
编辑 删除
被客户端工具的bug惊出一身冷汗
起因相关运维部门需要统计数据库的一些参数，请我审核一下。当我看到MySQL这页的事务隔离级别时候当场站起来了。因为大面积的都是RR级别（REPEATABLE READ）。有关这个并不是今天的主题，我就不深入说了。其实日常使用只要记住一点就够了。这是MySQL的默认隔离级别。在这个级别下，如果事务中（比如update）表没有索引，或者的SQL没有用到索引，操作的表是表级别锁。知道这个就行了，其他的一
-
编辑 删除
即使在MySQL8上也不是所有DDL都是秒过的
从前有些开发人员问我，如果在MySQL的一个大表上加字段怎么办？我一般都让他们尽可能停应用去做。直到MySQL升级到8以后这个问题得到了大大的缓解。 MySQL8的特性借鉴了Oracle 11G的设计，将表结构放在数据字典上管理。使得可以快速增加字段。但是有些场景上我还是遇到过盲点。因为有时候字段扩长度，我觉得很慢但是相关DBA告诉我很快。有时候我觉得应该很快，但是相关DBA告诉我很慢。
-
编辑 删除
MySQL undo膨胀了怎么办？
一般来说大事务大查询会导致undo变大。默认配置不会自动收缩。印象中OCP的考试中都没涉及到这样的考点。 记录了一次在实验环境下模拟收缩的实验。需要在参数文件中设置这几个参数;innodb_max_undo_log_size = 10M --回收后的初始状态一般是16M，即使这里设置是10M，最终通过实验测试得出也是16
-
编辑 删除
MySQL字符集带来的问题
下面说的 这些问题都是随意导致的。真的不是所有开发都可以写SQL，不是所有开发都能建表。这给后续的开发和运维工作带来很大的问题。 上周意外发现一个SQL，大致 SELECT * FROM a LEFT JOIN b ON s.xx = d.xx&nbs
-
编辑 删除
MySQL的特殊的表膨胀
一次数据库迁移过后，运维反馈数据库空间不足了。原来规划导入10G数据，现在占用空间比预期大量3倍。这个迁移过程我知道，中途还有insert into select的动作。但是处理的数据有点大，导致处理失败。 其实这也就是表膨胀的主要因素。 创建一个表，写入一些数据。看到这个表现在大小
-
编辑 删除
早就说了连接数别太多呀
本次场景是MySQL问题，有人问我监控显示，表缓存使用率99%，当前为100.0%。这是为什么？ 这个需要执行下面的命令来检查。可以看到参数table_open_cache定义了缓存4000个，实际达到的Open_tables是4000.这两个一个是variable，另外一个是状态status 一般来说，连接数据库以后us
-
编辑 删除
令人奔溃的数据和业务逻辑
前段时间不经意间看到一个数据库的日志，我将这个日志进行简化和脱敏。可能有人会说这个没有索引，是全表扫描。其实这个和索引没关系。不知道大家有没有觉得奇怪？为什么时间不一样，但是每次的行数都是一样的？关键是扫描行数和返回行数一模一样。（真实的数据是好几万行的扫描和好几万行的返回）我不相信每天产生的数据一条不差。这个和是不是有索引没有关系。这个时候我第一感觉就是，看看表里面的数据是什么样的吧？查看我脱敏
-
编辑 删除
匪夷所思的数据库延迟-
上周分析了一个数据库的主从延迟。起因是一个数据库做了一次迁移。迁移前配置为24C96G的物理机，迁移后为4C16G的虚拟机。迁移后发现主从有延迟。从硬件环境来说确实下降了许多。所以第一感觉就是硬件环境不足。 不过接下来的反馈有点莫名其妙。数据库是MySQL主从架构，既然是主从，那么就是要开启Binlog。根据处理此事的人员说，从库开启binlo
-
编辑 删除
MySQL SSL连接问题
一个开发转岗过来，我让他用开发工具连接数据库。随便给了一个MySQL8，地址是10.60.143.134他经过一系列编码发现无法连接，报错。具体如图1.图1可以看到现象是：com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link failure而造成这种现行的原因是定位到38行。而
-
编辑 删除
这个真没想到MySQL DDL也有隐患
没想到分区加了字段，居然影响后续操作。模拟一下当时出问题的场景。PA表为分区表，A表为和它一样表结构的非分区表。如图1 图1模拟写入几条数据mysql> insert into pa (a,create_time) values (1,'2020-10-01');Query OK, 1 row affected (0.01 sec)mysql> insert
-
编辑 删除
MySQL从库卡主了--读写分离也不能乱读
不少使用数据库的公司，数据库都建立主从。无论Oracle、MySQL还是PostgreSQL都会有这类应用。而TiDB这种分布式数据本身是一套高可用。当然我刚才提到的Oracle、MySQL还是PostgreSQL也早就有了自己的分布式。我们今天还是说主从的这种架构。一般主从可以起到硬件故障的灾备，但是现在的硬件情况，很少硬件损坏。大家用从库做读写分离或者说分析的也很多。（如果说现在谁家的硬件天天
