MySQL 字符串和数字隐式转换的 pitfall
Data truncation: Truncated incorrect
不要小看 MySQL，它出 warning 就一定有错误。
不要滥用 MySQL 字符串到decimal，和 decimal 到 string 的转换。这样有时候 MySQL 不只是 warning。
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2021-03-11
MySQL 的 MGR
MySQL 高可用架构的历史 MySQL 自带的主从复制机制，本身并不能实现自动高可用。 早期使用开源组件来搭 MySQL 集群的方案，使用 MMHA。当代 MySQL 官方自己主推的方案是 MySQL cluster。这些老的方案，优先保证MySQL服务的持续可用，在异常切换情况下，可能出现主机上部分数据未能及时同步到从库，造成主从切换后数据丢失。但是包括金融支付在内的一些业务，对于数据库服务既要求持续可用、也要求数据强一致（可以在性能上做出一些让步）。 因此，当代的 MySQL 官方提供了组复制（MySQL Group Replication）的方案，构建了新一代的 MySQL 高可用强一致服务。 Master-Slave（MS）架构高可用概述 MS架构高可用基础 高可用MySQL是依赖复制（Replication）技术实现的，复制解决的基本问题就是，让一台数据库服务器的数据同步到其它服务器上。MySQL数据库的复制有如下三个步骤。 在主库上把数据更改记录到二进制日志（Binary Log）中（这些记录被称为二进制日志事件）。 备库将主库上的日志复制到自己的中继日志（...
2021-03-18
MySQL 压缩
压缩算法 Table Compression InnoDB存储引擎是按照索引组织表（index-organized table）的方式组织数据的，数据存储在B-tree索引（clustered index/primary key & secondary index）中。Table Compression是针对整个表，和相关索引进行的，而不是单独的数据行。 B-tree页经常被更新，InnoDB会尽量减少B-tree节点的分裂（split），减少不必要的压缩和解压页。为此，InnoDB在每个B-tree页中都预留了未压缩的“modification log”空间，记录页的变更。对于update和insert的数据量较小时，会先写入“modification log”，不用立刻重构整个页。当“modification log”空间用完了，InnoDB解压该页，应用变更（apply），然后重新压缩。如果压缩失败，该B-tree叶节点就要进行分裂了。在写入量比较大的场景，比如某些OLTP应用，为了避免频繁压缩失败，InnoDB会在页中保留一些额外空间（padding），在“mod...
2020-02-19
MySQL 基本功
插件式架构 MySQL的插件式架构.xmind 索引问题 索引的出现是为了减少单一维度查询时，搜索数据的成本。 索引的基础架构 索引的分类 不同的存储引擎支持不同的索引数据结构。 MySQL 支持的索引类型至少包括：BTree索引、Hash索引、full-text全文检索、R-Tree索引。 Innodb 支持的索引数据结构只有 B+树。 B+树索引 B 树扩充了二叉平衡树，让每个节点能够存储的数据大大提升。 B+ 树从 B 树演变而来，B 树每个节点都存储数据，但高度高，只有查找离根节点近的数据的速度是快的；B+树所有数据都存储在叶子节点，所以查询到特定的数据必须走完查询路径，也因此 B+树的查找速度稳定，遍历全部数据和范围查找的算法稳定（不用上溯下钻）。两种数据结构，各有所长。 B+树的每个节点可以被认为是一个磁盘块（block）-可以认为 MySQL 的磁盘块等同于 OS 的数据页，大小通常为 4k/8k/16k。磁盘块通常是双层的，第一层表示存储的数据项（data entry），第二层表示指向子节点的指针（pointer）。但 B+树本身只有叶子节点真实数据，非叶子节...
2021-03-28
MySQL 存储引擎 InnoDB 技术内幕
这本书的电子版的一个博客。 InnoDB.xmind 前言 MySQL 是处理海量数据（尤其 是OLTP 写入）时仍能获得最佳性能的最佳选择之一，它的 CPU 效率可能其他任何基于磁盘的关系型数据库所不能匹敌的-但它应该能够匹敌 Redis。 Think Different 而不是 Think Differently，这意味着要思考不同的东西，而不只是思考不同的方式。 不要相信网上的传言，去做测试，根据自己的实践做决定。很多伟大的作者写的伟大的书里面，关于性能的说法都来源于他们个人的随身电脑的直观测试。 change buffer 是 inert buffer 的升级版本。 MySQL 体系结构和存储引擎 定义数据库和实例 数据库：物理操作系统文件或其他形式文件类型的集合。 实例：操作系统后台进程（线程和一堆共享内存）。 存储引擎：基于表而不是基于库的，所以一个库可以有不同的表使用不同的存储引擎。 InnoDB 将数据存储在逻辑的表空间中，这个表空间就像黑盒一样。 存储引擎不一定需要事务。比如没有 ETL 的操作，单纯的查询操作不需要考虑并发控制问题，不需要产生一致性视图。...
2020-02-03
MyISAM 和 InnoDB 的区别
参考：https://www.zhihu.com/question/20596402 区别： InnoDB 支持事务，MyISAM 不支持事务。这是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一； InnoDB 支持外键，而 MyISAM 不支持。对一个包含外键的 InnoDB 表转为 MYISAM 会失败； InnoDB 是聚集索引，MyISAM 是非聚集索引。聚簇索引的文件存放在主键索引的叶子节点上，因此 InnoDB 必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该过大，因为主键太大，其他索引也都会很大。而 MyISAM 是非聚集索引，数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。 InnoDB 不保存表的具体行数，执行 select count(*) from table 时需要全表扫描。而MyISAM 用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快； InnoDB 最小的锁粒度是行锁，MyIS...
2018-09-07
日期与时间
JSR 310 Java Date与Time API 新旧 API 的更迭 旧的 Java API 主要包括java.util.Date和java.util.Calendar 两个包的内容。这两个包的时间类型是可变的。如 Date 的实例可以通过 setYear 来产生变化。 JSR 310 中包括的日期类型主要有： 计算机时间：Instant，对应 java.util.Date，它代表了一个确定的时间点，即相对于标准Java纪元（1970年1月1日）的偏移量；但与java.util.Date类不同的是其精确到了纳秒级别。 人类时间：对应于人类自身的观念，比如LocalDate和LocalTime。他们代表了一般的时区概念，要么是日期（不包含时间），要么是时间（不包含日期），类似于java.sql的表示方式。此外，还有一个MonthDay，它可以存储某人的生日（不包含年份）。每个类都在内部存储正确的数据而不是像java.util.Date那样利用午夜12点来区分日期，利用1970-01-01来表示时间。这些类型的实例是 immutable 的，而且只能通过工厂方法创建。 时区...
