MySQL开发中的问题总结
1、关于查询字段的问题
创建数据库时，需要同时选择字符集和排序规则，字符集大家都知道是怎么回事，那排序规则干嘛用的呢？
排序规则：是指对指定字符集下不同字符的比较规则。其特征有以下几点：
1、 两个不同的字符集不能有相同的排序规则
2、 两个字符集有一个默认的排序规则
3、 有一些常用的命名规则：
*_bin: 表示的是binary case sensitive collation，也就是说是区分大小写的
*_cs: case sensitive collation，区分大小写
*_ci: case insensitive collation，不区分大小写
工作中使用到的 mysql 数据库 、以及阿里的AnalyticDB for MySQL 简称 ADB
这类型数据库，当你新建表不指定类型的时候，默认命名规则就是 case insensitive collation，所以建索引的时候，是不会区分 驼峰命名，当然也不会区分大小写，其实包括 你在做mysql 查询的时候，查询是不会区分大小写和是否是驼峰不影响查询结果。
3、关于建表的分区问题
在INNODB_SYS_INDEXES系统表中type代表索引的类型;
0:一般的索引,
1:(GEN_CLUST_INDEX)不存在主键索引的表,会自动生成一个6个字节的标示值，
2:unique索引,
3:primary索引;
所以当我们在分区表中创建索引时其实也是在每个分区中创建索引，每个分区维护各自的索引（其实也就是local index）；对于一般的索引(非主键或者唯一)没什么问题由于索引树中只保留了索引key和主键key(如果存在主键则是主键的key否则就是系统自动生成的6个的key)不受分区的影响；但是如果表中存在主键就不一样了，虽然在每个分区文件中都存在主键索引但是主键索引需要保证全局的唯一性就是所有分区中的主键的值都必须唯一（唯一键也是一样的道理），所以在创建分区时如果表中存在主键或者唯一键那么分区列必须包含主键或者唯一键的部分或者全部列（全部列还好理解，部分列也可以个人猜测是为了各个分区和主键建立关系），由于需要保证全局性又要保证插入数据更新数据到具体的分区所以就需要将分区和主键建立关系,由于通过一般的索引进行查找其它非索引字段需要通过主键如果主键不能保证全局唯一性的话那么就需要去每个分区查找了，这样性能可想而知。
索引方式：
性能依次降低
1.主键分区
主键分区即字段是主键同时也是分区字段，性能最好
2. 部分主键+分区索引
使用组合主键里面的部分字段作为分区字段，同时将分区字段建索引（见下面详细说明）
3.分区索引
没有主键，只有分区字段且分区字段建索引
4.分区+分区字段没有索引
只建了分区，但是分区字段没有建索引
总结
因为每一个表都需要有主键这样可以减少很多锁的问题，由于上面讲过主键需要解决全局唯一性并且在插入和更新时可以不需要去扫描全部分区，造成主键和分区列必须存在关系；所以最好的分区效果是使用主键作为分区字段其次是使用部分主键作为分区字段且创建分区字段的索引，其它分区方式都建议不采取。
划重点： MYSQL的分区字段，必须包含在主键字段内
3、关于索引的问题
1、普通数据库 以mysq 为例
在建表的时候，如果需要建索引，这个时候 如果要加下划线 例如 index_userId，这样索引不会因为 你字段选的是 case insensitive collation，不区分大小写。而导致查询不精确。
2、关于logstore
在开发中，会使用到日志源 也就是 logstore（阿里常用的存机器打日志的数据库）, 简单说下 它是在project 和endpoint 的。 一个endpoint （地域划分 cn-hangzhou）逻辑关系 一个地域可以有多个 project，一个project下可以有多个logstore。阿里这边都是按照这样划分的。
logstore 包括 什么？
日志有 日志组 、日志主题 topic 、 分区（Shard）
这里说的是 新建的logstore 是 全文索引，查询的时候 如果 需要排序 或者 需要 过滤 分组时，这时候 要建字段索引，字段索引查询时 会优先于全文索引。
还有
在开发中，有的日志 比如 操作类型的日志，它们都是 json 形式，对象里放数组，数据里继续嵌套。 这时候，要做日志的的解析就会有些头疼。用一函数 json_value 取值的时候， 要每个对象的跟都去一下。