一、请问计数用这个MySQL+redis方案如何：
1.开启事务（程序中的事务）
2.MySQL插入数据
3.原子更新redis计数
4.如果redis更新成功提交事务，如果redis更新失败回滚事务。

二、.net和java程序代码的事务和MySQL事务是什么关系，有什么相关性？

老师 ，我这边有几个问题 ：

1. 看到老师回复评论说 count(id) 也是走普通索引 ，那是不是也算是优化了 ， 我以为 count(字段) 是走的聚集索引 。老师的意思是 count(字段) 是走二级索引，但是不一定是数据最少的索引树的意思是么

2. count(*) 的话， innodb 还会有取数判空这样的判断逻辑么 ，还是直接取行数 +1 了 ， 还是按所取索引类型分情况。 允许为 null 的索引是不是行数比较少， 取的总数会不会有问题呢

3. 我这边试了一下 ， 库里总共 30w 数据 。 第一次用 count(*) 是 120多ms , 第二次就是 60多 ms 。 第三次用了 count(1) ，也是60多ms 。 请问 count(*) 这两次的前后时间差是什么原因，也会走缓存 ？

4. 另一个问题是一个题外话 ，我看老师的例子事务级别应该都是 rr 。 我偶然看到我们公司事务隔离级别是 rc 。 我比较惊讶，就去问 DBA 为什么是 rc 而不是默认的 rr 。 她说一般都是用的 rc ，我想问现在公司一般都是 rc 么， 请问老师现在用的隔离级别是什么 ？？ 在我的印象里 ，rr 保证事务的隔离性会更好一些吧 。 我google 了一下， rc 会不会在某些场景下出现一些问题，但是没有查出来相关结果。老师能不能讲解一下，rc 的话会在哪些场景下会踩坑么 。 （我之前码代码都是按照 rr 级别下的思维码的代码）

老师我先问个本章之外的问题:
1.rr模式下,一张表上没有主键和唯一键,有二级索引c.如果是一张大表,删除一条数据delete t where c=1.
在主库上利用二级索引,在根据虚拟的主键列回表删除还挺快.但是在备库上回放特别慢,而且状态是system lock,是因为binlog event里没有包含虚拟主键列.导致在备库回放的时候,必须全表扫描,耗时特别久?还是其他原因

2.回放过程中,在备库delete一条语句是被阻塞的,insert又是可以的,说明只在记录上的X锁没有gap锁。
但是如果在主库session A begin,delete where c=1.在开启一个session B,在主库上操作也是delete阻塞,insert正常.不过等session A执行完成,不提交.insert都阻塞了,说明最后上了gap锁。有点没明白这儿的上锁逻辑是什么？

3.还有就是备库回放binlog,相对于主库的一条update语句流程来说,从库回放哪些流程是省略了的啊,
server层的应该都省略了,应该主要是引擎层的回放,这里有点模糊从库是怎么回放的binlog event?
因为第一个问题从库回放的时候,从库上的二级索引貌似没起作用,直接就在聚簇索引上做的更新。

感谢老师

老师：
1.count(*) 不取值，
         InnoDB还做遍历表的操作吗，也不用给server层返回值吗？
2.count(1) 不取值，
        但是要遍历表。原文中：
        “server 层对于返回的每一行，放一个数字“1”进去”
        这个“返回的每一行” ：到底返回的啥？是每一行记录吗？还是形式的返回空行，然后用1填充？

3. count(1),count(*),count(主键id)
       这三个做比较，哪个会快？时间消耗在哪个环节？
      是否遍历表；是否取值；返回给server层内容 细节上从哪个角度考虑？
         

谈谈自己的理解,有不对之处还请老师指出:
数据一致性问题目前来说主要分为三类
1.主从不一致
解决办法:半同步复制after_commit,after_sync,MGR(after_prepare)。但是都不能完成满足完全实时一致,由于等待的ack点不同,相对来说一致性的强度是递增.
2.数据库与缓存的不一致
解决办法:读操作直接读缓存,写操作先更新到数据库,淘汰缓存(程序需要保证两个操作的原子性).由于该key的缓存已经清理掉,那么下次读的时候需要先读数据库,在重建缓存.
由于redis是单线程,保证了一个操作的原子性.可以通过设置appendfsync always来保证每次操作都把该操作记录并落盘到aof文件里(不过一般redis该值为everysec),毕竟使用redis的目的不是为了保证acid.还是要根据业务来选择
3.一个事务跨多个节点或者多种数据库(分库分表和银行转账这种例子)
目前好像都是通过2pc,3pc来保证的。

count(字段值):如果该字段上有null值.每行的行头有一个标记位,标记该行是否为null.所以多了一层判断。相对更耗时
count(主键id):即便是选择的有null值的二级索引,但是也可以挺快的正确计数。因为null的话字段值虽然为null,但是该行上主键id以及指向聚簇索引该id的指针还是存在的,所以不影响计数,也不用做判断,直接遍历该二级索引,取出id值,按行累加就行。
count(1)和count(*):看官方文档上说是5.7.18版本之前是扫描聚簇索引,之后是二级索引。虽然不取值,只计数。但是二级索引比聚簇索引需要扫描的页数相对来说更少,这应该也是一种优化,不过我做测试percona版本的5.6都是选择了二级索引
这期干货挺多的,学会了如果某表上有count比较多的操作,最好是用count(1)或者count(*),然后选择一列占用字节数最少的建立索引(比如tinyint类型)

还有个问题请教下老师:
1.如果某列设置为not null建立索引.那么是不是count(id)走该索引和count(该列)效率是不是一样的？都不用做判断,两者都是需要把整个二级索引传给server层计数?还是说count(id)只需要传id,而count(字段)只需要传字段值给server层做计数？

把该讲内容总结为几个问题, 大家复习的时候可以先尝试回答这些问题检查自己的掌握程度:
    1.
count(*)的实现方式在MySAM引擎和InnoDB引擎的实现方式各是怎么样的? 为什么会有这种不同?
    2.
使用缓存保存count总数存在什么问题?
    3.
如果使用一场单独的表来记录其他各张表的记录数的话,是怎么解决统计结果不精确的问题的?
    4.
count(字段),count(id),count(1), count(*)各自是怎么样的执行机制, 效率排序是怎么样的?

1：又刷新了认知，先给结论(之前不知从哪看的，以为count(主键id)性能最佳)
按照效率排序的话，count(字段)<count(主键 id)<count(1)≈count(*)，所以老师建议，尽量使用 count(*)。
2：count(*)这么慢，我该怎么办？
要么忍，要么自己动手记录，如果自己记录的话，老师建议使用数据库来弄，感觉使用数据库自己弄的思路可以建议MySQL实现一下？
3：count()的语义是啥？
首先，不同的存储引擎实现方式不同
MyISAM 引擎把一个表的总行数存在了磁盘上，因此执行 count(*) 的时候会直接返回这个数，效率很高；
而 InnoDB 引擎就麻烦了，它执行 count(*) 的时候，需要把数据一行一行地从引擎里面读出来，然后累积计数。
以下针对innodb来说
count() 是一个聚合函数，对于返回的结果集，一行行地判断，如果 count 函数的参数不是 NULL，累计值就加 1，否则不加，最后返回累计值。
4：count(字段)怎么计数？
4-1：如果这个“字段”是定义为 not null 的话，一行行地从记录里面读出这个字段，判断不能为 null，按行累加；
4-2：如果这个“字段”定义允许为 null，那么执行的时候，判断到有可能是 null，还要把值取出来再判断一下，不是 null 才累加。
从引擎返回的字段会涉及到解析数据行，以及拷贝字段值的操作。
5：count(主键 id)怎么计数？
对于 count(主键 id) 来说，InnoDB 引擎会遍历整张表，把每一行的 id 值都取出来，返回给 server 层。server 层拿到 id 后，判断是不可能为空的，就按行累加。从引擎返回的 主键id 会涉及到解析数据行，以及拷贝字段值的操作。
6：count(1)怎么计数？
对于 count(1) 来说，InnoDB 引擎遍历整张表，但不取值。server 层对于返回的每一行，放一个数字“1”进去，判断是不可能为空的，按行累加。
7：count(*)怎么计数？
对于count(*)来说，并不会把全部字段取出来，而是专门做了优化，不取值。count(*) 肯定不是 null，按行累加。
8：现在终于弄明白这些count()背后的计算原理啦！非常感谢！另外，分析这些count()的原则如下：
8-1：server 层要什么就给什么；
8-2：InnoDB 只给必要的值；
8-3：现在的优化器只优化了 count(*) 的语义为“取行数”，其他“显而易见”的优化并没有做。
这几条原则对别的性能差别的分析也是OK的吧？
达到同样的目标，谁绕的弯越多做的事情越多就会越慢，性能自然不咋滴！不过知道每种达到目的的路径轨迹是一个难点，如果知道谁不喜欢走捷径呢？

歪个楼请教个业务中遇到的问题：
表结构如下：
 CREATE TABLE `tablename` (
  `id` int(10) NOT NULL AUTO_INCREMENT,
  `uid` bigint(20) NOT NULL DEFAULT '0',
  `status` tinyint(1) NOT NULL DEFAULT '1' ,
  `date` varchar(8) NOT NULL DEFAULT '0' COMMENT '日期',
  `source` varchar(20) NOT NULL DEFAULT '' COMMENT '来源',
  `ctime` datetime NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '创建时间',
  `etime` datetime NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `idx_uid_date` (`uid`,`date`),
  KEY `idx_ctime` (`ctime`)
) ENGINE=InnoDB AUTO_INCREMENT=685725 DEFAULT CHARSET=utf8

其中 UNIQUE KEY `idx_uid_date` (`uid`,`date`)

查询指定date下uid个数：
方式一：select count(uid) from tablename where date = '20181201';
+------------+
| count(uid) |
+------------+
| 8330 |
+------------+
方式二：select count(distinct uid) from tablename where date = '20181201';
+---------------------+
| count(distinct uid) |
+---------------------+
| 8243
+---------------------+
方式三：
select count(*) from (select distinct uid from tablename where date = '20181201') as t;
+----------+
| count(*) |
+----------+
| 8330 |
+----------+
与方式一查询结果一致

问题：为何方式二和方式一、三的结果不一样呢？