tlxamulet的博客

因为表越多，意味着数据库引擎做出最优查询计划的代价就越高，在有限时间内得出的一定不是最优解，甚至可能是最次解。超过百万记录的表就算大表，而超过500万记录的表要考虑分区或分表，否则，表太大，表结构调整、数据修改、备份恢复都会有性能问题。表、存储过程、视图要有统一的命名规范，例如：表以t_打头，存储过程以sp_打头，视图以v_打头；数据库和表的字符集用UTF8，如有emoji表情包的需求，必须使用UTF8MB4。多表关联尽量用join而不是逗号，这样能清晰的看到表间的关联关系，可维护性更好。

解释一下type、possible_keys 和key等几个字段的含义。

mysql索引使用B+树。详细原理可参考。

用户定义变量 是用户根据需要自己定义的变量，用户变量不用提前声明，在用的时候直接用 “@变量 名” 使用就可以，其作用域为当前会话，即在会话1中定义的变量在会话2中是不能使用的；注：之前讲的2个@符号是系统变量名，一个@符号是用户自定义变量。

现象：如果有事务正在修改某张表T，此时执行alter table T语句会挂住。另外，将alter table放在一个事务中，模拟大表的长时操作，发现此时查询、删除这张表的记录均无问题。是否说明alter table并不锁表呢？我们先来看看alter table的原理，mysql5.7的手册上有一段alter table有两种算法，一种是就地（inplace）修改或重建表，一种是把数据复制到新表，最后把新表rename回老表（rename动作是原子的，而且非常快）。

NameNode主要是用来保存HDFS的元数据信息，比如命名空间信息，块信息等。当它运行的时候，这些信息是存在内存中的。但是这些信息也可以持久化到磁盘上。只有在NameNode重启时，edit logs才会合并到fsimage文件中，从而得到一个文件系统的最新快照。但是在产品集群中。因此为了克服这个问题，我们需要一个易于管理的机制来帮助我们减小edit logs文件的大小和得到一个最新的fsimage文件，这样也会减小在NameNode上的压力。

collection：相当于db的表document：相当于表的记录。

解释下这个3层的配置系统。最底层的是disk库和config file。这里需要注意，这里的config file就是传统的配置文件，默认为/etc/proxysql.cnf，ProxySQL启动时，主要是从disk库中读取配置加载到内存并最终加载到runtime生效，只有极少的几个特定配置内容是从config file中加载的，除非是第一次初始化ProxySQL运行环境(或者disk库为空)。中间层的是memory，表示的是内存数据库，其实就是main库。

表的个数：生产上常用的表就10来个。sharding cluster + replica set方式部署：9个shard server， 每个shard server 1主2从， 大量数据写入时或对大表创建索引时，可能有主从复制延迟问题。实测下来，20亿表的索引创建导致主从延时4小时，因为从表在建索引的时候会停掉主从复制。一个shard server挂掉，恢复起来很慢，一般要半个小时。而且一个shard server挂掉，目前会导致整个集群不可用，。

Transport Client已经快要废弃了，官方推荐使用High Level REST Client。

这个写法很巧妙，使用了mysql的ON DUPLICATE KEY UPDATE的语法，首次insert，后续每次都是在当前值的基础上update。当然，使用数据库生成唯一ID的方式是有缺陷的，它只适用于单库，如果分了库，就做不到全系统唯一，只能用雪花算法了。基于数据库生成唯一ID有很多手段：oracle有funcNextval等函数，也可以用自增列。其中，category参数代表一种业务类别，num是该次生成唯一ID的个数。前者依赖于oracle，后者不通用，一张表只能生成一种业务的唯一ID。