摘要：
mysql客户端和服务器之间的通信协议是“半双工”的，这意味着，在任何一个时刻，要么是由服务器向客户端发送数据，要么是有客户端想服务器发送数据，这两个动作不能同时发生。所以我们也无须将一个消息切成小块独立来发送。缺点是没法进行流量控制。max_allowed_packet控制请求大小。 查询状态： 阅读全文
posted @ 2020-04-19 21:27
l2c
阅读(170)
评论(0)
推荐(0)
摘要：
1.查询性能低下最基本的原因是访问的数据太多。访问了太多的行，有时候也可能是访问了太多的列。 2.请求超过实际需要的数据：1.查询不需要的记录 limit杜绝2.多表关联时返回全部列 3.总是取出全部列 无法完成索引覆盖这类优化，但并不总是坏事 3.重复查询相同的数据，注意缓存 响应时间：服务时间+ 阅读全文
posted @ 2020-04-18 23:33
l2c
阅读(170)
评论(0)
推荐(0)
摘要：
innoDB B+树的存储结构结构 决定了B-Tree索引支持一下查询类型： key(last_name,firset_name,job) 1.全值匹配 和索引中的所有列进行匹配：查找姓l 名cc 职业工程师的人 2.匹配最左列 可查找所有姓为l的人，即用索引的第一列 3.匹配列前缀 查找所有以J开 阅读全文
posted @ 2020-04-05 15:12
l2c
阅读(156)
评论(0)
推荐(0)
摘要：
mysql的alter table操作的性能对打表来说是个大问题。 mysql执行大部分修改表结构的方法是用新的结构创建一个空表，从旧表中查出所有的数据插入新表，然后删除旧表。这样操作就可能需要花费很长时间，如果内存不足而表又很大，而且还有很多索引的情况下尤其如此。 一般而言大部分AlterTabl 阅读全文
posted @ 2020-04-04 23:24
l2c
阅读(306)
评论(0)
推荐(1)
摘要：
1.冗余一列做排序 2.缓存衍生值列。 3.缓存表和汇总表 实时计算统计值是很昂贵的操作，因为要么需要扫描表中的大部分数据，要么查询语句只能在某些特定的索引上才能有效运行，而这类特定索引一般会对update操作有影响，所以一般不希望创建这样的索引 4.影子表 阅读全文
posted @ 2020-04-04 22:12
l2c
阅读(144)
评论(0)
推荐(0)
摘要：
1.太多的列： mysql的存储引擎api工作时需要在服务器层和存储引擎层之间通过行缓冲格式拷贝数据，然后在服务器层将缓冲内容解码成各个列。从行缓冲中将编码过的列转换成行数据结构的操作代价是非常高的。 2.太多的关联 mysql限制了没哥关联操作最多只能有61张表，单个查询最好在12个表以内做关联。 阅读全文
posted @ 2020-04-04 21:44
l2c
阅读(103)
评论(0)
推荐(0)
摘要：
1.更小的通常更好 选择不会超过范围的最小类型 2.简单就好 例如，整型比字符操作代价更低，因为字符集和校对规则(排序规则)使字符比较比整形比较更复杂。 3.尽量避免null 如果查询中包含可为null的列，对mysql来说更难优化，因为可为null的列使得索引，索引统计和值比较 都更复杂。 可为n 阅读全文
posted @ 2020-04-04 15:47
l2c
阅读(229)
评论(0)
推荐(0)
摘要：
1.show table status like 'user' 2.alter table mytableEngine=InnoDB 需要执行很长时间，mysql会按行将数据从原表复制到一张新的表中，消耗大量i/o，原表上会加上读锁。 3.insert into innodb_table selec 阅读全文
posted @ 2020-03-27 22:48
l2c
阅读(127)
评论(0)
推荐(0)
摘要：
emmm一年前居然还做过...好吧 这里用了hash来存子串的快照，O(n^2)后面看看有没有更好的解法 阅读全文
posted @ 2020-03-22 23:54
l2c
阅读(142)
评论(0)
推荐(0)
摘要：
看一下starter里如何注册不同的redisTemplete实例的： 看一下这2个Serializer： 在看下最下面的RedisDao： 经过实验发现GenericJackson2JsonRedisSerializer是个关键，保障了incr和get set时都能被正确序列化和反序列化.并且当我 阅读全文
posted @ 2020-03-22 14:12
l2c
阅读(219)
评论(0)
推荐(0)
浙公网安备 33010602011771号