感冒了，可太难受了，感觉像是行尸走肉。这两天应该全国都在变冷吧，大家一定要注意身体啊。少熬夜了，我感觉我就是熬夜导致免疫力下降了。
今天就说点简单的咯，说下Android端用的数据库引擎——SQLite。
介绍下SQLite
为什么Android端要使用这个数据库引擎。
谈谈基本语法和市面上的封装库。
介绍下SQLite
SQLite是一个进程内的库，实现了自给自足的、无服务器的、零配置的、事务性的SQL 数据库引擎。它是一个零配置的数据库，这意味着与其他数据库一样，您不需要在系统中配置。就像其他数据库，SQLite 引擎不是一个独立的进程，可以按应用程序需求进行静态或动态连接。SQLite 直接访问其存储文件。
它是用C语言构建，在Android系统架构中的系统运行库层的c/c++程序库部分。
为什么Android端要使用这个数据库引擎。
SQLite有如下特性，也就决定了其在移动端的地位：
不需要一个单独的服务器进程或操作的系统(无服务器的)。
SQLite 不需要配置，这意味着不需要安装或管理。
一个完整的 SQLite 数据库是存储在一个单一的跨平台的磁盘文件。
SQLite 是非常小的，是轻量级的，完全配置时小于 400KiB，省略可选功能配置时小于250KiB。
SQLite 是自给自足的，这意味着不需要任何外部的依赖。
SQLite 事务是完全兼容 ACID 的，允许从多个进程或线程安全访问。
SQLite 支持 SQL92(SQL2)标准的大多数查询语言的功能。
SQLite 使用 ANSI-C 编写的，并提供了简单和易于使用的 API。
SQLite 可在 UNIX(Linux, Mac OS-X, Android, iOS)和 Windows(Win32, WinCE, WinRT)中运行。
谈谈基本语法。
先说说SQLite的语法，分为创建，增，删，查，改。
创建
1)创建语法：
CREATE TABLE main.表名(
   id INTEGER PRIMARY KEY AUTOINCREMENT,
   name TEXT,
   account TEXT,
   pwd TEXT,
   age INT
);
AUTOINCREMENT代表自增主键。
2)在Android中的用法：
public class MySQLite extends SQLiteOpenHelper {

    public static String DB_NAME="main.db";


    public MySQLite(Context context, int version) {
        super(context, DB_NAME, null, version);
    }


    @Override
    public void onCreate(SQLiteDatabase db) {
         //数据库第一次创建时被调用
        db.execSQL("create table 表名 (_id integer primary key autoincrement)");

    }

    @Override
    public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
       //数据库版本变化时调用
    }
}
增。
1)基本语法
INSERT INTO USER (name,pwd) VALUES ("jimu", "123456");
2)Android中用法
    ContentValues values = new ContentValues();
    values.put("name","jimu")
    values.put("pwd","123456")
    sqlhelper.getWritableDatabase().insert(表名, null, values);
删
1)基本语法
//删除数据
DELETE FROM USER WHERE name = "jimu";

//删除数据库
DROP TABLE 数据库名.表名;
2)Android中用法：
//删除数据
getWritableDatabase().delete(表名, "name=?", new String[]{"jimu"});
//删除数据库
getWritableDatabase().execSQL("DROP TABLE IF EXISTS "+ TABLE_NAME);
查
1)基本语法
SELECT * 或者 具体的字段
FROM 表名
[ WHERE  ]
[ GROUP BY 列名 ]
[ HAVING  ]
[ ORDER BY 列名 <DESC> | <ASC> ]
[ LIMIT 行数 OFFSET 偏移量]
2)Android中用法
getWritableDatabase().query(TABLE_NAME_PERSON,null,"name=?",new String[]{"jimu"},null,null,null);
改
1)基本语法
UPDATE USER SET name = "jimu2" WHERE id = 1;
2)Android中用法：
getWritableDatabase().update(String table,ContentValues values, String whereClause, String[] whereArgs)

最后说说市面上的数据库框架
主要有以下几款：
OrmLite，LitePal(郭神的框架)，GreenDao，Room(Jetpack组件)
网上也有很多对于各个框架的比较，这里就不细说了。我觉得都可以用，没有很明显的优缺点。如果你的项目框架是MVVM架构的话，就直接用room吧，毕竟是jetpack组件，对Livedata，paging等有比较好的支持。
参考
https://juejin.cn/post/6891411303798308872
拜拜
最后祝我早日康复，然后给大家带来更多优质的文章吧。晚安。

在实际项目开发过程中，设计数据库表时经常遇到需要主键自增的场景。那如何实现Oracle的主键自增呢，这里我们记录一种最常用的方式：sequence + trigger。
就是利用Oralce的序号和触发器来实现字段的自增，下面直接来看一个完整的例子。
一、创建表结构
这里我们简单创建一张表做例子，其中表中的id字段就是我们后面准备用来作为自增的字段。
create table T_EMP(ID NUMBER not null,EMP_CODE VARCHAR2(64),EMP_NAME VARCHAR2(64))；
二、创建序列(sequence)
这里创建自增序列，用于后面和上表的关联。
CREATE SEQUENCE T_EMP_SEQUENCEMINVALUE 1 --最小值NOMAXVALUE --不设置最大值START WITH 1 --从1开始计数INCREMENT BY 1 --每次加1NOCYCLE --一直累加，不循环NOCACHE; --不建缓冲区
三、创建触发器(trigger)
创建触发器，把表和序列关联起来，并设定每当表中新增数据的时候触发。
代码如下，
CREATE OR REPLACE TRIGGER T_EMP_TRIGGER BEFORE INSERT ON T_EMP FOR EACH ROW WHEN(NEW.ID IS NULL)BEGIN  SELECT T_EMP_SEQUENCE.NEXTVAL INTO:NEW.ID FROM dual;END;
四、测试
上面sequence和trigger都创建好之后，就可以添加数据测试了。这里我们直接insert几条数据，注意看id字段的变化就可以了。
INSERT INTO T_EMP (EMP_CODE, EMP_NAME)VALUES ('zhangsan', '张三');INSERT INTO T_EMP (EMP_CODE, EMP_NAME)VALUES ('lisi', '李四');INSERT INTO T_EMP (EMP_CODE, EMP_NAME)VALUES ('wangwu', '王五');
我们看下结果，
从上图看出，已经实现表中id字段的自增，大功告成。

	

前言
在《阿里巴巴 Java 开发手册》第五章 MySQL 规定第九条中，强制规定了单表的主键 id 必须为无符号的 bigint 类型，且是自增的。为什么会这样强制规定呢？
为什么
通常主键 id 的数据类型有两种选择：字符串或者整数，主键通常要求是唯一的，如果使用字符串类型，我们可以选择 UUID 或者具有业务含义的字符串来作为主键。
对于 UUID 而言，它由 32 个字符+4 个'-'组成，长度为 36，虽然 UUID 能保证唯一性，但是它有两个致命的缺点：
不是递增的。MySQL 中索引的数据结构是 B+Tree，这种数据结构的特点是索引树上的节点的数据是有序的，而如果使用 UUID 作为主键，那么每次插入数据时，因为无法保证每次产生的 UUID 有序，所以就会出现新的 UUID 需要插入到索引树的中间去，这样可能会频繁地导致页分裂，使性能下降。
太占用内存。每个 UUID 由 36 个字符组成，在字符串进行比较时，需要从前往后比较，字符串越长，性能越差。另外字符串越长，占用的内存越大，由于页的大小是固定的，这样一个页上能存放的关键字数量就会越少，这样最终就会导致索引树的高度越大，在索引搜索的时候，发生的磁盘 IO 次数越多，性能越差。
对于整数的数字类型，MySQL 中主要有 int 和 bigint 类型。其中 int 占用 4 个字节，bigint 占用 8 个字节，这和 Java 中的 int 和 long 对应。如果使用无符号的 int 类型作为主键，那么主键的最大值为 2^32-1，即 4294967295，这个值不到 43 亿，似乎有点太小了。虽然一张表的数据，我们不可能让其达到 43 亿条(太大会影响性能)，但是对于频繁进行插入、删除的表来说，43 亿这个值是可以达到的。而如果使用无符号的 bigint 类型的话，主键的最大值可以达到 2^64-1，这个数足够大了，如果以每秒插入 100 万条数据计算的，58 万年以后才能达到最大值。所以 bigint 作为主键的数据类型，完全不用担心超过最大值的问题。
而强制要求主键 id 是自增的，则是为了在数据插入的过程中，尽可能的避免索引树上页分裂的问题。
自增 id 用完后会出现什么现象
虽然前面已经解释了 bigint 作为主键已经足够我们使用了，但是我们不妨再考虑一下，如果真的碰到主键 id 被用完时，MySQL 会出现什么想象。
1. 指定主键
下面我们以 int 类型作为主键来举例说明一下，为了方便演示，我创建了一个示例表，由于 int 类型能表达的值最大为 4294967295，所以我让表的主键的初始自增值为 4294967295。建表语句如下：
CREATE TABLE `test` (
`id` int ( 11 ) unsigned  AUTO_INCREMENT COMMENT '主键id',
`name` varchar ( 20 ) NOT NULL COMMENT '姓名',
PRIMARY KEY ( `id` )
) ENGINE = INNODB AUTO_INCREMENT = 4294967295 COMMENT '测试表';

# 然后向表中插入一条数据
insert into test(name) values("小明"); ### 插入成功
当我们再向表中插入一条数据时：
insert into test(name) values("小红");
发现插入失败，显示的错误信息如下图所示：
这是因为我们插入第一条数据的时候，获取到的主键 id 为 4294967295，然后 MySQL 尝试将这个自增值加 1 的时候，发现它已经达到了 int 能表达的最大值了，因此就保持不变。当我们再插入第二条数据的时候，获取的自增值还是 4294967295，所以就出现的主键冲突的错误。
2. rowid 作为主键
上面的例子是我们在表中明确指定了将哪一列作为主键列，而如果我们没有指定主键，那么 MySQL 的 InnoDB 引擎就会使用系统 rowid 作为表的主键。这个 rowid 是所有表共享的一个变量，所有没有主键的表都会使用这个 rowid 作为主键。每插入一行数据，这个全局的 rowid 的值就会加 1。
这个 rowid 实际上使用的是无符号的 bigint 类型，因此会占用 8 个字节，但是 InnoDB 只会用后面的 6 个字节来表示主键，前面的两个字节并不用来表示主键，因此 rowid 能表示主键的最大值为 2^48-1。如果达到最大值后，也就是后面的 48bit 的值全是 1 后，再尝试进行+1 操作时，就会向高位进位，后面的 48 bit 就变成了 0，所以此时表示的主键的值就变成了 0，后面再一次自增，就又从 1 开始了。因此如果使用 rowid 作为主键的话，当达到最大值后，会出现数据覆盖。
为什么说会出现数据覆盖呢？我们可以通过下面这个例子来说明。
假设现在有一行数据，它隐藏的主键 id(rowid)值为 1，name 列的值为'小明'。当某一天 rowid 达到 2^48-1 后，再次自增时，rowid 表示的主键值就从 0 开始了，当我们再插入一条 name 等于'小红'的数据是，rowid 自增得到的值也表示的是 1，这样新插入的数据就变成了(1,小红)，这就覆盖了前面(1,小明)这条数据。
自增 id 用完了怎么办
虽然 bigint 足够我们使用了，但如果真的出现了极端情况，bigint 也用完了(有些奇葩面试官可能就是这么刚)，那应该怎么办呢？
没辙了，只能选择字符串作为主键了。实际上如果真的出现了这种情况，我们应该思考的是我们的表设计的有问题了，在出现这么大数据量之前，我们就应该提前想到分库分表了。
总结
本文从《阿里巴巴 Java 开发手册》中的一条强制规定出发，分析了为什么要求单表的主键必须是无符号 bigint 类型的自增主键，一是因为 bigint 能表示的数足够大，二是自增能使主键 id 有序，在插入时能尽量避免索引树的页分裂。
然后又举例说明了自增主键 id 用完了，会出现什么样的现象。如果表指定了主键，当主键自增值用完后，再插入数据就会出现主键冲突的异常；如果表没有指定主键，InnoDB 则会使用全局的 rowid 作为主键，当 rowid 的主键自增值达到上限后，就会从 1 开始循环，最终覆盖数据。对比这两者，我们应该更倾向于前者，因为它至少能让开发人员知道系统出了异常，而后者则直接在开发人员不知道的情况下覆盖了数据，这是不可取的。
其他
索引数据结构之 B-Tree 与 B+Tree(上篇)
索引数据结构之 B-Tree 与 B+Tree(下篇)
MySQL 为什么不用数组、哈希表、二叉树等数据结构作为索引呢
MySQL 索引的工作原理
MySQL 中 order by 语句的实现原理以及优化手段

一、自增值保存在哪儿？
不同的引擎对于自增值的保存策略不同
1.MyISAM引擎的自增值保存在数据文件中
2.InnoDB引擎的自增值，在MySQL5.7及之前的版本，自增值保存在内存里，并没有持久化。每次重启后，第一次打开表的时候，都会去找自增值的最大值max(id)，然后将max(id)+步长作为这个表当前的自增值
select max(ai_col) from table_name for update;

在MySQL8.0版本，将自增值的变更记录在了redo log中，重启的时候依靠redo log恢复重启之前的值
二、自增值修改机制
如果字段id被定义为AUTO_INCREMENT，在插入一行数据的时候，自增值的行为如下：
1.如果插入数据时id字段指定为0、null或未指定值，那么就把这个表当前的AUTO_INCREMENT值填到自增字段
2.如果插入数据时id字段指定了具体的值，就直接使用语句里指定的值
假设，某次要插入的值是X，当前的自增值是Y
1.如果X<Y，那么这个表的自增值不变
2.如果X>=Y，就需要把当前自增值修改为新的自增值
新的自增值生成算法是：从auto_increment_offset（初始值）开始，以auto_increment_increment（步长）为步长，持续叠加，直到找到第一个大于X的值，作为新的自增值
三、自增值的修改时机
创建一个表t，其中id是自增主键字段、c是唯一索引，建表语句如下：
CREATE TABLE `t` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `c` int(11) DEFAULT NULL,
  `d` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `c` (`c`)
) ENGINE=InnoDB;

假设，表t里面已经有了(1,1,1)这条记录，这时再执行一条插入数据命令：
insert into t values(null, 1, 1); 

执行流程如下：
1.执行器调用InnoDB引擎接口写入一行，传入的这一行的值是(0,1,1)
2.InnoDB发现用于没有指定自增id的值，获取表t当前的自增值2
3.将传入的行的值改成(2,1,1)
4.将表的自增值改成3
5.继续执行插入数据操作，由于已经存在c=1的记录，所以报Duplicate key error（唯一键冲突），语句返回
对应的执行流程图如下：



在这之后，再插入新的数据行时，拿到的自增id就是3。出现了自增主键不连续的情况
唯一键冲突和事务回滚都会导致自增主键id不连续的情况
四、自增锁的优化
自增id锁并不是一个事务锁，而是每次申请完就马上释放，以便允许别的事务再申请
但在MySQL5.0版本的时候，自增锁的范围是语句级别。也就是说，如果一个语句申请了一个表自增锁，这个锁会等语句执行结束以后才释放
MySQL5.1.22版本引入了一个新策略，新增参数innodb_autoinc_lock_mode，默认值是1
1.这个参数设置为0，表示采用之前MySQL5.0版本的策略，即语句执行结束后才释放锁
2.这个参数设置为1

普通insert语句，自增锁在申请之后就马上释放
类似insert … select这样的批量插入数据的语句，自增锁还是要等语句结束后才被释放

3.这个参数设置为2，所有的申请自增主键的动作都是申请后就释放锁
为了数据的一致性，默认设置为1



如果sessionB申请了自增值以后马上就释放自增锁，那么就可能出现这样的情况：

sessionB先插入了两行数据(1,1,1)、(2,2,2)
sessionA来申请自增id得到id=3，插入了(3,5,5)
之后，sessionB继续执行，插入两条记录(4,3,3)、(5,4,4)

当binlog_format=statement的时候，两个session是同时执行插入数据命令的，所以binlog里面对表t2的更新日志只有两种情况：要么先记sessionA的，要么先记录sessionB的。无论是哪一种，这个binlog拿到从库执行，或者用来恢复临时实例，备库和临时实例里面，sessionB这个语句执行出来，生成的结果里面，id都是连续的。这时，这个库就发生了数据不一致
解决这个问题的思路：
1）让原库的批量插入数据语句，固定生成连续的id值。所以，自增锁直到语句执行结束才释放，就是为了达到这个目的
2）在binlog里面把插入数据的操作都如实记录进来，到备库执行的时候，不再依赖于自增主键去生成。也就是把innodb_autoinc_lock_mode设置为2，同时binlog_format设置为row
如果有批量插入数据（insert … select、replace … select和load data）的场景时，从并发插入数据性能的角度考虑，建议把innodb_autoinc_lock_mode设置为2，同时binlog_format设置为row，这样做既能并发性，又不会出现数据一致性的问题
对于批量插入数据的语句，MySQL有一个批量申请自增id的策略：
1.语句执行过程中，第一次申请自增id，会分配1个
2.1个用完以后，这个语句第二次申请自增id，会分配2个
3.2个用完以后，还是这个语句，第三次申请自增id，会分配4个
4.依次类推，同一个语句去申请自增id，每次申请到的自增id个数都是上一次的两倍
insert into t values(null, 1,1);
insert into t values(null, 2,2);
insert into t values(null, 3,3);
insert into t values(null, 4,4);
create table t2 like t;
insert into t2(c,d) select c,d from t;
insert into t2 values(null, 5,5);

insert … select，实际上往表t2中插入了4行数据。但是，这四行数据是分三次申请的自增id，第一次申请到了id=1，第二次被分配了id=2和id=3，第三次被分配到id=4到id=7
由于这条语句实际上只用上了4个id，所以id=5到id=7就被浪费掉了。之后，再执行insert into t2 values(null, 5,5)，实际上插入了的数据就是(8,5,5)
这是主键id出现自增id不连续的第三种原因
五、自增主键用完了
自增主键字段在达到定义类型上限后，再插入一行记录，则会报主键冲突的错误
以无符号整型（4个字节，上限就是$2^{32}-1$）为例，通过下面这个语句序列验证一下：
CREATE TABLE t ( id INT UNSIGNED auto_increment PRIMARY KEY ) auto_increment = 4294967295;
INSERT INTO t VALUES(NULL);
INSERT INTO t VALUES(NULL);

第一个insert语句插入数据成功后，这个表的AUTO_INCREMENT没有改变（还是4294967295），就导致了第二个insert语句又拿到相同的自增id值，再试图执行插入语句，报主键冲突错误
推荐资料：
https://time.geekbang.org/column/article/80531