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
2017-11-15
MariaDB 调优相关
本文主要摘译自这里。 MySQL 曾经有独立的公司。但那间公司后来被 Sun 微系统公司获取了。 Sun 微系统公司又被 Oracle 获取了。原 MySQL 开发者担心 MySQL 成为闭源软件，因此成立了一家SkySQL 公司维护开源的 MySQL 分支—MariaDB。 MariaDB 支持的存储引擎包括： InnoDB/XtraDB 后者是前者的加强版，属于事务性存储引擎，也叫 ACID-compliant（ACID 遵从的）。XtraDB 是 Percona 开发的存储引擎，整体向下兼容。使用普通的 mysqldump 会耗尽 cpu（因为要把数据库转化成正经的 SQL 语句）。而 xtrabackup 在大库上的备份、还原、冗余都表现得更好（因为像 Oracle 一样是二进制备份吗？）。 TokuDB。另一个事务性存储引擎。以高压缩率著称（最高25倍压缩）。适合小空间存储大数据。 MyISAM。MySQL 上最古老的存储引擎。非事务性存储引擎，只支持表级锁，不支持...
2018-05-29
JPA 的 id 生成策略
JPA 有一个@GeneratedValue注解，有一个strategy attribute，如@GeneratedValue(strategy = GenerationType.IDENTITY)。 常见的可选策略主要有IDENTITY和SEQUENCE。 GenerationType.IDENTITY要求底层有一个 integer 或者 bigint 类型的自增列（ auto-incremented column)。自增列的赋值必须在插入操作之后发生，因为这个原因，Hibernate 无法进行各种优化（特别是 JDBC 的 batch 处理，一次 flush 操作会产生很多条insert 语句，分别执行）。如果事务回滚，自增列的值就会被丢弃。数据库在这个自增操作上有个高度优化的轻量级锁机制，性能非常棒。 MySQL 支持这种 id 生成策略， 使用 MySQL 应该尽量使用这个策略，即使它无法优化。 JPA 用它生成 id，会一条一条地插入新的 entity。 GenerationType.SEQUENCE数据库有一个所谓的 sequence 对象，可以通过 select...
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...
2018-11-15
MySQL 中的引号
标准的 SQL 中只允许用单引号表达字符串类型。有些 SQL 方言允许使用双引号包裹字符串，如 MySQL，有些则不允许，如 Oracle。 反引号是专门用来表达 identifier 的。
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...
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）。但...
