赶集网dba石展分享归纳

字段不要使用null值。查询，索引方面不利。
如果是整型，int，仅仅是设置 not null还不够。最好是这种一个默认的值0。为什么？

text类型处理性能低于varchar。
尽量不要使用text/blog数据类型，使用的话。拆分到单独的表中存储。

与阿里巴巴一个思想：大容量的数据不要存到数据库中去，比如图片，url。


将字符存储转换为数字存储。比如ip用int存储。
为什么字符型数据建立索引，索引的名称要建立前缀：idx_pinyin
是考虑字母的区分度吗？字母越长越容易区分？

它们习惯建立索引的命名规则是：idx_字段名。


拒绝大SQL，拆解成多条简单SQL。对于高并发的情况下，非常有利，避免一条复杂的sql语句把表锁死。
由于一条sql只能在一个cpu中计算，那么最好是做简单的sql，可以减轻cpu负担。

简单sql的缓存命中率更高。

多条sql合并成一条复杂的sql一步解决的思路，是传统的思想。对于互联网高并发，要求高性能的情况下，不适合。
思想：把复杂的东西拆分成小步骤。一个一个做。一次性去做复杂的。耗费很多时间。


尽量少用外键，尽量少用存储过程。少用触发器。
减少使用mysql函数对结果进行处理。

作者也是强调，需要多少字段就用多少字段。

将or改为in。in的效率要更高。建议n数量小于200。不同的字段进行or查询的时候。比如 "a=x or b=y"将or可以修改成union,
where a=x union b=y。同一个字段做成in比较好。in(1,2,3)。不同字段没办法。




联想起一道题目，将or中的顺序指定。是不是使用in就解决了？


select catid from jay_category where catid=1 or catid=6 or catid=4
无解。or 默认是按照id，从小到大列出的。

实时统计：用memcache，双向更新，凌晨跑基准。
非实时统计：尽量用单独统计表，定期重算


把join连接查询，拆分成单条sql语句，分多不操作。性能要高。可以减少大并发情况下锁表。

作者告知，remark=115127 与 remark="115127"的查询性能是有区别的。使用引号速度更快。不知道什么原因。


批量导入数据方面：
尽量不要使用INSERT ... SELECT延迟同步出错。复制可能出现异常情况。
成批插入比当行插入更快，所以：insert values，values的速度要比拆分成多条
插入语句速度要快。符合成批载入数据比单行载入数据要快。
可以考虑大数据载入的时候用load data

大一点的公司。程序员编写的每条sql都会经过dba进行分析确认，这样保证性能。
dba毕竟是专业的数据库人员。对于数据库的原理，查询性能优化有丰富的经验。

一个单表，数据量在500万-1000万的时候就要考虑分表。所以使用bigint是没有多少实际一样的。

int(10) 与int(1)所存储的数据额度其实是一样的。后面的10表示是宽度。就是每个值存储的时候占用多少个位数。


他的思维：从存储空间角度去考虑。存储空间越少。对性能影响越好。

在传统的数据库系统中，是建议，尽量使用更少是sql完成更多是事情。也就是尽量少到使用一条sql实现查询。
但是在mysql中就不适合，因为mysql被设计成适合高效的连接和断开，响应查询。所以很适合拆分成多条sql去实现。
假设一个情况：在5000个qps中(每秒响应5000个sql请求)，如果一条sql查询超过了一秒，就会导致整个拖慢，就像现实生活中，堵车，只要其中一辆车抛锚了，就会导致所有的车都无法前进，被卡死了。本身道路宽度就有限。

有个思想：现实生活中，堵车，道路宽度有限。如果单纯依靠扩宽道路来解决交通问题，是解决不了根源问题的，因为道路宽度即便扩宽，也有更多车去拥挤，扩宽是有极限，扩到不能扩了才麻烦。应该是一种调度思想。


数据库的连接：即用即关掉。马上关掉。即便是后面代码需要用到，也可以马上关掉，然后再次连接
发帖：数据先insert into入表。然后图片要传入图片系统。他建议是insert数据后。要关掉数据库连接。这样子可以避免一个问题：如果图片系统出现问题。数据库连接一直没关掉，就会导致大量sleep等待。


永远不要用程序对数据库显式的加锁。加锁是方便。但是会造成一些不可控的问题：把海豚绑死了。它怎么跑得快？
调试和排查问题很难(很难找到是那段程序加了锁,php执行的时候是一个代码副本)。高并发情况下很危险。


如果涉及到需要锁定的，使用事务机制，相对值修改、commit前二次校验冲突。

表的字段数控制在20-50个字段。50个纯int字段。20个char字段。计算方式：
硬盘3秒以上

单表的体积控制在1g。char类型大约是500万行数据
1g/500万=200个字节 20个字段
1g/1000万


他们会把left join查询拆分成多次去获取数据。a left join b 先从a表获取where条件的数据，然后又去b表聚合(这个时候就释放了对a表的锁)