之城的专栏

对象中有expire三个时间相关的字段。注意： 可以解决问题，但是需要在每个时间字段都加注解，比较繁琐， 不推荐。对象中加上注解如下：/***/) {= null) {Sqlite数据库有自己单独的字段类型处理方式， Mybatis对其支持并不完善， 从发现问题到解决问题我中间尝试了各种方法， 最终还是通过覆盖Mybatis的类来解决问题了。Sqlite对于时间自动转换成时间戳的方式也不太好，我改成了字符串的方式，查看和显示比较直观。

我个人项目中，不想使用太重的数据库，而内嵌数据库中SQLite又是最受欢迎的， 因此决定采用这个数据库。可是JPA并不支持Sqlite，这篇文章就是记录如何解决这个问题的。由于我个人比较喜欢使用最新版本的各种包，所以容易遇到各种问题， 多找找网络信息，多花点心思往往都容易找到解决方案的。

修改mysql大表字段长度没有锁表的原因分析

现在的业务中不能避免的会使用联表查询的操作， MYSQL中对于联表查询也有自己的优化的。在联表查询的时候，联表的字段一定要创建索引，联表查询的时候选择小表作为驱动表， left join和right join 要按照语义设置驱动表。select * from t t1 right JOIN t_user t2 on t2.id =t1.id 这个语句中 t2表示驱动表select * from t t1 right JOIN t_user t2 on t2.id =t1.id

主备库同步的时候， 毕竟是在两台机器上的，延迟问题肯定是有的。主备同步延迟主库提交日志了后， 主库是后台线程读取日志发送给从库的，如果主库压力大， 后台同步线程可能会延迟一点读取到日志发送日志会有网络延迟， 但是现在主备库都是在公司的内部局域网中，这个延迟可以忽略不计备库接收到日志后，消费这些日志信息执行会耗时。备库机器性能差有些公司可能备库真的只是备库， 不会转正的，所以选择一个性能差的机器做备库， 或者一个机器上装上个四五个备库， 这样自然会导致备库的延迟表上没有主键主库使用内部ro

一般线上的MYSQL的数据库都会有备库， 主备库之间的同步都是使用的Bin Log日志来实现的。备库建议设置成只读备库只读的话， 它只能进行查询语句的操作 ， 不会误改数据库导致主备不一致防止在备库切换成主库过程中，双写的时候出现不一致的问题可以通过数据库是否只读的状态可以判断出主库和备库bin log如何同步的备库需要设置成只读，设置主库的ip和用户名密码， 以及开始同步的bin log起点偏移量备库和主库之间维持长连接主库有一个单独的dump_thread线程， 会在后台把日志传

BinLog的写入机制binlog日志在事务没有提交之前会想写入到binlog cache中， 每个线程都有一个binlog cache。在事务提交后才会一次性写入到文件系统的缓存file page中。然后mysql会根据你的sync_binlog配置决定是否马上刷新到磁盘中。sync_binlog=0 的时候，表示每次提交事务都只 write到file page中，不 fsync到磁盘；sync_binlog=1 的时候，表示每次提交事务都会执行 fsync；sync_binlog=N(N

MYSQL的加锁规则丁奇老师总结的加锁规则里面，包含了两个“原则”、两个“优化”和一个“bug”。原则 1：加锁的基本单位是 next-key lock。希望你还记得，next-key lock 是前开后闭区间。原则 2：查找过程中访问到的对象才会加锁。优化 1：索引上的等值查询，给唯一索引加锁的时候，next-key lock 退化为行锁。优化 2：索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候，next-key lock 退化为间隙锁。一个 bug：唯一索引上的范围查询会访问

在MYSQL的RR隔离级别下， MYSQL也解决了幻读的问题。 主要是依靠两个特性解决的， 一个是MVCC（一致性快照） 一个是间隙锁。MVCC如何解决幻读begin select count(*) from table where id >10 ...... 一系列的其他操作 ...... select count(*) from table where id >10 commit上面的sql 语句如果在执行的过程中（中间的一系列操作中）， 其他的事务新增了

为何有些查询一条记录的语句也很慢借用丁奇老师的建表语句mysql> CREATE TABLE `t` ( `id` int(11) NOT NULL, `c` int(11) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB; delimiter ;; create procedure idata() begin declare i int; set i=1; while(

索引字段上使用函数在索引字段上面使用函数会是的索引的检索功能失效。select count(*) from tradelog where month(t_modified)=7;上面的语句中对t_modified字段使用了month函数， 导致t_modified上面的索引失效， 由于索引的快速检索能力是依赖于索引的有序性来完成的， 是先根据树来找到对应的记录位置， 在按照顺序往后找就能找到所有的记录了，如果使用了函数的方式会破坏这个有序性，如果同样找到一个符合要求的位置，你不知道该往前找还是往后找，

内存临时表用 order by rand() 来实现这个逻辑。explain SELECT NAME FROM t_user ORDER BY rand() LIMIT 2;这个语句的意思很直白，随机排序取前 3 个。虽然这个 SQL 语句写法很简单，但执行流程却有点复杂的。可以看到Extra字段中显示Using temporary 表示使用了临时表，Using filesort，表示的是需要执行排序操作。 使用了排序操作。内存临时表上进行了排序操作。整个操作流程：创建一个临时表， 表里

日常的开发中，总是会碰到排序的需求， 一般的排序都是使用Order By 的语句的，但是order by 语句的作用机制是怎样的呢？Explain查看排序的语句的执行情况Extra 这个字段中的“Using filesort”表示的就是需要排序，MySQL 会给每个线程分配一块内存用于排序，称为 sort_buffer。 看到使用id的时候，并没有使用Using filesort， 这是因为 Id字段本来就是有序的，取出的数据本身就是有序的，不用在排序了， 而使用Name字段排序就需要使用sort_

mysql中的数据分为表结构数据和表真实数据， 在MYSQL8.0 之前， 表结构是存储在单独的.frm后缀文件中， 8.0之后， 会存储在系统数据表中。innodb_file_per_table参数 innodb_file_per_table 设置成ON 会使用单独的frm文件存储表结构， 设置成off是使用系统数据表存储表结构。建议这个参数设置成ON . 因为表结构很小，使用单独的frm文件，方便维护删除表操作 drop table . 此命令会删除表空间（表数据和表结构）但是d

随着表记录的增加，select count(*) from table 统计表信息的语句变的越来越慢了。count(*)的实现方式在MyISAM引擎中， 表的总行数是实时更新存储在磁盘中。 因此这个统计的语句就十分快速, 但是如果统计语句加上了where条件，磁盘中存储的总行数就无效了， 就要实时累计计算了。在InnoDB引擎中， 执行这个统计语句的时候，就会扫描表的所有数据实时累计计算出总数来，这个过程自然很慢了InnoDB为何不把总数记录到一个特定位置这是由于它要支持事务的可重复读隔离

目录合理的建表把常用字段提取出来建表把Text等超长字段单独存放到冗余表中与其他表关联的外键建立索引适当的冗余字段选择合适的字段类型建立合理的索引值差异大的字段适合建索引查询频繁的字段建立索引使用覆盖索引避免回表不要建立过多的索引使用Explain查看下Sql的执行计划sql语句的注意事项避免使用子查询大型表的分页查询limit 需要优化避免类型转换 无论是隐式的还是显式的避免字符串的编码转换使用预编译查询避免使用having使用union all 代替 union必要的情况才使用事务使用合理框架和设置缓存