EXPLAIN
SELECT md5_code
FROM nuclear_price FORCE INDEX(nuclear_time)
WHERE nuclear_time BETWEEN '2020-03-18' AND '2020-06-17'
GROUP BY md5_code
HAVING COUNT(md5_code) >= 4
ORDER BY NULL
优化效果出来了，索引直接使用了 nuclear_time，数据量缩小了一半了，开始查询。
二：验证优化效果-查询
效果还行，数据出来了。
三：其他优化点
1：指定ORDER BY NULL禁止排序:
2：Mysql 查询缓存配置 地址，如果没有配置查询缓存，不建议配置。
查询缓存的作用就是当查询接收到一个和之前同样的查询，服务器将会从查询缓存种检索结果，而不是再次分析和执行上次的查询。这样就大大提高了性能，节省时间。
1.配置查询缓存
修改配置文件，修改[mysqld]下的query_cache_size和query_cache_type（如果没有则添加）。
query_cache_size：表示缓存的大小
query_cache_type：有3个值，表示缓存那种类 型的select结果集，query_cache_type各个值如下：
0或off：关闭缓存
1或on：开启缓存，但是不保存使用sql_no_cache的select语句,如不缓存select sql_no_cache name from wei where id=2
2或demand：开启有条件缓存，只缓存带sql_cache的select语句，缓存select sql_cache name from wei where id=4
例子的配置为下，配置完成重启Mysql服务器即可。
query_cache_size=256M
query_cache_type=1
四：查询缓存问题 参考地址
SHOW VARIABLES LIKE '%query_cache%';
SHOW STATUS LIKE 'qcache%';
生产库建议配置MySQL，配置后重启。不建议开启查询缓存
SHOW VARIABLES LIKE '%query_cache%';
SHOW STATUS LIKE 'Qcache%';
# 如果Qcache_lowmem_prunes的值非常大，则表明经常出现缓冲不够的情况;
如果Qcache_hits的值非常大，则表明查询缓冲使用非常频繁，如果该值较小反而会影响效率，那么可以考虑不用查询缓冲;
Qcache_free_blocks，如果该值非常大，则表明缓冲区中碎片很多。
● “Qcache_free_blocks”：Query Cache 中目前还有多少剩余的blocks。如果该值显示较大，则说明Query Cache 中的内存碎片较多了，可能需要寻找合适的机会进行整理。
● “Qcache_free_memory”：Query Cache 中目前剩余的内存大小。通过这个参数我们可以较为准确的观察出当前系统中的Query Cache 内存大小是否足够，是需要增加还是过多了；
● “Qcache_hits”：多少次命中。通过这个参数我们可以查看到Query Cache 的基本效果；
● “Qcache_inserts”：多少次未命中然后插入。通过“Qcache_hits”和“Qcache_inserts”两个参数我们就可以算出Query Cache 的命中率了：
Query Cache 命中率= Qcache_hits / ( Qcache_hits + Qcache_inserts )；
● “Qcache_lowmem_prunes”：多少条Query 因为内存不足而被清除出Query Cache。通过“Qcache_lowmem_prunes”和“Qcache_free_memory”相互结合，能够更清楚的了解到我们系统中Query Cache 的内存大小是否真的足够，是否非常频繁的出现因为内存不足而有Query 被换出
● “Qcache_not_cached”：因为query_cache_type 的设置或者不能被cache 的Query 的数量；
● “Qcache_queries_in_cache”：当前Query Cache 中cache 的Query 数量；
● “Qcache_total_blocks”：当前Query Cache 中的block 数量；
Query Cache 的限制
Query Cache 由于存放的都是逻辑结构的Result Set，而不是物理的数据页，所以在性能提升的同时，也会受到一些特定的限制。
a) 5.1.17 之前的版本不能Cache 帮定变量的Query，但是从5.1.17 版本开始，Query Cache 已经开始支持帮定变量的Query 了；
b) 所有子查询中的外部查询SQL 不能被Cache；
c) 在Procedure，Function 以及Trigger 中的Query 不能被Cache；
d) 包含其他很多每次执行可能得到不一样结果的函数的Query 不能被Cache。
鉴于上面的这些限制，在使用Query Cache 的过程中，建议通过精确设置的方式来使用，仅仅让合适的表的数据可以进入Query Cache，仅仅让某些Query 的查询结果被Cache。
一：问题时间范围查询所有数据的同数据存在超过4次的数据，检索查询时已经没有速度了，直接不响应。优化方向：①给md5_code、nuclear_time字段加索引。②给sql语句后面加order by null。③调整where条件里字段的查询顺序，有索引的放前面。④给所有where条件的字段加组合索引。⑤用子查询的方式，先查where条件里的内容，再去重。SQL分析后的结果是：可能用到索引：nuclear_time,md5_code实际用到索引：md5_co...
收到疯狂的慢查询及请求超时报警，通过metrics分析出来自mysql请求的异常，cli —> show proceslist 看到很多慢查询。 先前该sql是没有的，后面因为数据量的增长才出现了这问题。 虽然feeds表大到一个亿，但因为feeds流信息有近期热的特征，所以不是因为 innodb_buffer_pool_size 低效引起的io频繁。 后来经过进一步explain执行计划分析得出了原因，mysql查询优化器选择了他认为高效的索引。
mysql查询优化器大多数情况是靠谱的! 但是你的sql语言含有多个索引时就要注意了，往往最后的结果令人有些彷徨了。因为mys
这篇博客跟MySQL高级性能优化—Explain博客有关联，主要讲的是Extra的Using filesort和Using temporay如何避免，不懂Using filesort和Using temporay的朋友建议去看一看这篇MySQL高级性能优化—Explain博客。
1. 排序优化
在使用order by的时候，经常出现Using filesort, 我们应避免Using fileso...
文章目录协程协程概念：协程的实现：1、yield、send2、yield from3、asyncio.coroutine和yield from4、async和await
协程概念：
协程： 又称微线程，纤程，协程是一种用户态的轻量级线程。
协程的作用： 在执行A函数的时候，可以随时中断，去执行B函数，然后中断继续执行A函数（可以自动切换），协程过程并不是函数调用（没有调用语句），过程很像多线程，然而协程只有一个线程在执行。
必须在只有一个单线程中实现并发
用户可以在自己的程序中保存多个控制流
数据库语句查询慢优化[快了一半!]
最近遇到SQL语句的操作时,当表进行group by联查,表中语句又很多的情况下,出现查询时间过长的状况!!!()
操作人员总是在投诉我们的查询慢,迫不得已,自己做了下DB维护的优化操作记录下–(菜鸡的我:只能将时间(10s)缩短到1s~2s,平均时间检测快了一半)
===>欢迎各位大佬支招,上来碾压我的优化方法,给我火箭般的执行速度
1.主要思想:
运用建临时表的的思想
if object_id('tempdb..#temp') is not null dr
1. 分页查询优化
在平时开发中，免不了使用分页，很多时候我们业务系统实现分页功能可能会用如下sql实现：
mysql> select * from employees limit 10000,10;
这种查询方式表示从表 employees 中取出从 10001 行开始的 10 行记录。看似只查询了 1
在MySQL中，可以使用DATE_FORMAT函数将时间按照指定格式进行格式化，然后再使用GROUP BY语句将结果按照格式化后的时间进行分组查询。
例如，如果想要按照年份和月份进行分组查询，可以使用如下语句：
SELECT DATE_FORMAT(date_column, '%Y-%m') AS formatted_date, COUNT(*) AS count
FROM table_name
GROUP BY formatted_date;
其中，`date_column`是存储时间的列名，`table_name`是表名，`'%Y-%m'`表示将时间格式化为年份-月份的形式。`formatted_date`是格式化后的时间，`COUNT(*)`是统计每个时间段的数量。
你可以根据自己的需求修改DATE_FORMAT函数中的格式字符串，例如，`'%Y'`表示只按照年份分组查询。
springcloud启动eureka报错java.lang.ClassNotFoundException: com.sun.jersey.api.core.DefaultResourceConfig
94383
