mysqlsql优化方法
Ⅰ mysql sql优化之 优化GROUP BY 和 DISTINCT
创建表tb_point 表
准备空的tb_box表
函数
编写存储过程，给tb_box表添加100万条数据
修改关联数据
好于
优于
在执行以下语句时会报错：
前面在 https://www.jianshu.com/p/95e50fd017ea 文章中有提到这个问题，是直接修改sql_mode将 ONLY_FULL_GROUP_BY直接干掉。但是在《高性能mysql》中有一段话是这样的：
那么既然指出不要直接修改 sql_mode，那么我们应该如何让冲突的GRUOPBY语句正确执行呢？
文中有提到，可以使用max()和min()函数来实现；但是这种方式使用max和min函数较真的人可能会说这样写的分组查询有问题，确实如此。但是如果更加在乎查询效率，这样做也无可厚非。
如果，实在无法接受使用上面那种方式的话，可以这样使用子查询的方式来进行查询：
书上对于这种方式有描述如下：
这样写更满足关系理论，但是成本有点高，因为子查询需要填充临时表，而子查询中创建的临时表是没有任何索引的。
作者认为这样写对性能有影响。
但是从我测得结果来看，子查询的耗时反而更少。性能反而更佳。这个子查询耗时0.4秒。而使用max方式耗时0.8秒。几乎一倍。我的mysql版本是 5.7.22-log
为了解其中的原因，我们查看它的执行计划：
可见，因为子查询而产生了一层 DERIVED 临时表，但是这个临时表的Extra字段有显示 Using index、key里面显示自建索引。说明用到了索引。这是查询性能可观的一个重要原因吧；
另外我分别使用 SHOW PROFILE命令查看各部分耗时，对比之下。没看到有哪部分耗时差别特别大，使用JOIN、MAX 耗时比上子查询耗时都差不多是1倍
有些时候对一没有建立索引的字段，进行GRUOP BY时。会产生Using filesort 文件内排序。因为GRUOP BY是在排序的基础上进行分组的。
如下面sql：
如果业务上不对排序有要求。那么就可以禁止GRUOP BY的排序：
这样就把Using filesort给干掉了！ 执行时间 1.237
当然，多数情况是多排序有要求的。此时也可以在GRUOP BY后面使用DESC和ASC关键字，使分组的结果集按需要的方向排序。如下：
分组查询的一个变种就是要求mysql对分组结果再进行一次超级聚合。可以使用GROUP BY WITH ROLLUP 来实现这种逻辑，但可能性能不佳。因为通过查询计划分析出它是使用 Using temporary; Using filesort 来实现的。
使用WITH ROLLUP，查询时间2.531秒。不使用0.774 秒。
1、所以，很多时候。我们在应用程序中做超级聚合是最好的！
2、当然也可使用UNION ALL 来实现：
3、还可以通过FROM子句嵌套使用子查询：
Ⅱ SQL语句的几种优化方法
1、尽可能建立索引，包括条件列，连接列，外键列等。
2、尽可能让where中的列顺序与复合索引的列顺序一致。
3、尽可能不要select *，而只列出自己需要的字段列表。
4、尽可能减少子查询的层数。
5、尽可能在子查询中进行数据筛选 。
Ⅲ 怎么进行mysql数据库优化
有八个方面可以对mysql进行优化：
1、选取最适用的字段属性
MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。
2. 使用连接（JOIN）来代替子查询(Sub-Queries)
MySQL从4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。
3、使用联合(UNION)来代替手动创建的临时表
MySQL从4.0的版本开始支持union查询，它可以把需要使用临时表的两条或更多的select查询合并的一个查询中。在客户端的查询会话结束的时候，临时表会被自动删除，从而保证数据库整齐、高效。
4、事务
尽管我们可以使用子查询（Sub-Queries）、连接（JOIN）和联合（UNION）来创建各种各样的查询，但不是所有的数据库操作都可以只用一条或少数几条SQL语句就可以完成的。更多的时候是需要用到一系列的语句来完成某种工作。但是在这种情况下，当这个语句块中的某一条语句运行出错的时候，整个语句块的操作就会变得不确定起来。设想一下，要把某个数据同时插入两个相关联的表中，可能会出现这样的情况：第一个表中成功更新后，数据库突然出现意外状况，造成第二个表中的操作没有完成，这样，就会造成数据的不完整，甚至会破坏数据库中的数据。要避免这种情况，就应该使用事务，它的作用是：要么语句块中每条语句都操作成功，要么都失败
5、锁定表
尽管事务是维护数据库完整性的一个非常好的方法，但却因为它的独占性，有时会影响数据库的性能，尤其是在很大的应用系统中。由于在事务执行的过程中，数据库将会被锁定，因此其它的用户请求只能暂时等待直到该事务结束。其实，有些情况下我们可以通过锁定表的方法来获得更好的性能。
6、使用外键
锁定表的方法可以维护数据的完整性，但是它却不能保证数据的关联性。这个时候我们就可以使用外键。
7、使用索引
索引是提高数据库性能的常用方法，它可以令数据库服务器以比没有索引快得多的速度检索特定的行，尤其是在查询语句当中包含有MAX(),MIN()和ORDERBY这些命令的时候，性能提高更为明显。
8、优化的查询语句
绝大多数情况下，使用索引可以提高查询的速度，但如果SQL语句使用不恰当的话，索引将无法发挥它应有的作用。
Ⅳ mysql的sql语句优化5种方式
只有5种吗？我知道十种以上的说。
索引（没我得全表查询了）
改变数据储引擎（MyISAM没事务再也不用担心锁表了）
增加冗余数来减少连表查询数（消耗硬盘空间减少CPU使用）
调整查询顺序减少查询量优先（数量少了连表的笛卡儿积也少了）
全文索引（文字长度有限制，而且IO使用量会大增，但是妥妥的快）
查询尽量不要用函数（函数可是不走索引的哦亲）
查询变量类型要提前对好减少系统负担（我提前改变了系统你就不用检测了）
升级服务器硬件（没什么是氪金解决不了的）
配置好临时表空间，合理理由临时表减少主表查询抢资源（唯我独查）
合理理由函数减少系统的判断（明明都能确认内容不同你用UNION 系统还是傻傻的查一遍是否重复UNION ALL则跳过这个步骤同理 inner join 和 left join 也一样）
强制走索引（复合索引的情况有时候手动走比系统判断要好哦）
脏读、幻读等（你堵车我绕路）
数据归档，迁移（没用的数据要进仓哦，别占着主表的资源）
表的碎片整理（迁移后碎片整理更健康哦亲）
索引重构（数据都走了索引也应该重构一下才能保证速度哦）
善用存储过程（串N个表（N大于10）的查询千万别一个SQL到底，分布式查询在吧结果集合并吧骚年）
预处理数据（mysql也有job哦，对于经常要子查询的数据可以先弄个明细表根据主表在后台进行补完，查询的时候就更方便了）
懒得说了。。。。。。。。。。。。。。。。。。
Ⅳ sql优化的N种方法
1.SQL语句中IN包含的值不应过多:
例如：select id from t where num in(1,2,3) 对于连续的数值，能用between就不要用in了； 实测速度差距不是很大.
2.SELECT语句务必指明字段名称:
禁止用 * 来查询 ,禁止用 * 来查询 ,禁止用 * 来查询 , 查找哪个字段,就写具体的字段.
select * from user_test WHERE address=15988;
select address from user_test WHERE address=15988;
3.只查询一条数据的时候，使用limit 1
【这个很有用】
4.避免在where子句中对字段进行null值判断:
【实测：null值的判断依然走了索引】
explain select uid from user_test WHERE phone is null;
5.避免在where子句中对字段进行表达式操作:
6.对于联合索引来说，要遵守最左前缀法则:
例如组合索引(id,name,sex) 使用的时候,可以id 或者id,name . 禁止直接name,或者sex.会导致联合索引失败
注意: id, name,sex 这三个字段填写顺序不会有影响, mysql会自动优化成最左匹配的顺序.
前三条sql都能命中索引,中间两条由于不符合最左匹配原则,索引失效.
最后一条sql 由于有最左索引id 所以索引部分成功,部分失效. id字段索引使用成功.
7.尽量使用inner join，避免left join：
如果连接方式是inner join，在没有其他过滤条件的情况下MySQL会自动选择小表作为驱动表，但是left join在驱动表的选择上遵循的是左边驱动右边的原则，即left join左边的表名为驱动表。
【实测：不是很准确，具体用explain测试】
8.注意范围查询语句:
对于联合索引来说，如果存在范围查询，比如between、>、<等条件时，会造成后面的索引字段失效。
解决办法: 业务允许的情况下,使用 >= 或者<= 这样不影响索引的使用.
explain select * from user_test where uid=10 and name='张三' and phone='13527748096';
explain select * from user_test where uid between( 1 and 10) and name ='张三' and phone='13527748096';
9.不建议使用%前缀模糊查询:
例如 : LIKE“%name”或者LIKE“%name%”，这种查询会导致索引失效而进行全表扫描。但是可以使用LIKE “name%”。
explain select * from user_test where uid=10 and uid like "%1" ;
explain select * from user_test where uid=10 and uid like "1%" ;
10.在 where 子句中使用 or 来连接条件，如果or连接的条件有一方没有索引,将导致引擎放弃使用索引而进行全表扫描
解决办法: 将or连接的双方都建立索引,就可以使用.
explain select * from user_test where uid=10 or name='张三';
11.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。(此处存在疑点,我本人测试的时候,发现索引还是能使用到)
12.字符串类型的字段 查询的时候如果不加引号'' ,会导致自动进行隐式转换,然后索引失效
Ⅵ mysql如何优化以下语句，查询耗时太久了
根据所描述的问题，可尝试在mms_profitcenter 的FOrderID ，FSuffix列上建立索引，再查询试试。 下面提供30种mysql常用优化方法供参考：
1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
2.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
3.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0
4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num=10 or num=20
可以这样查询：
select id from t where num=10
union all
select id from t where num=20
5.下面的查询也将导致全表扫描：
select id from t where name like '%abc%'
若要提高效率，可以考虑全文检索。
6.in 和 not in 也要慎用，否则会导致全表扫描，如：
select id from t where num in(1,2,3)
对于连续的数值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
7.如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
select id from t where num=@num
可以改为强制查询使用索引：
select id from t with(index(索引名)) where num=@num
8.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where num/2=100
应改为:
select id from t where num=100*2
9.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where substring(name,1,3)='abc'--name以abc开头的id
select id from t where datediff(day,createdate,'2005-11-30')=0--'2005-11-30'生成的id
应改为:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'
10.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
11.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
12.不要写一些没有意义的查询，如需要生成一个空表结构：
select col1,col2 into #t from t where 1=0
这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：
create table #t(...)
13.很多时候用 exists 代替 in 是一个好的选择：
select num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num)
14.并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。
15.索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。
16.应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。
17.尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
18.尽可能的使用 varchar/nvarchar 代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
19.任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。
20.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。
21.避免频繁创建和删除临时表，以减少系统表资源的消耗。
22.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。
23.在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。
24.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。
25.尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。
26.使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。
27.与临时表一样，游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。
28.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。
29.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。
30.尽量避免大事务操作，提高系统并发能力。
Ⅶ 如何进行SQL性能优化
这里分享下mysql优化的几种方法。
1、首先在打开的软件中，需要分别为每一个表创建 InnoDB FILE的文件。
Ⅷ mysql数据库如何优化谁能给出点具体的解决方案
1、explain：解释sql的执行计划，后边的sql不执行
2、explain partitions ：用于查看存在分区的表的执行计划
3、explain extended：待验证
4、show warnings:
5、show create table:查看表的详细的创建语句，便于用户对表进行优化
6、show indexes :产看表的所有索引，show indexes from table_name，同样也可以从information_schema.statistics表中获得同样的信息。cardinality列很重要，表示数据量。
7、show tables status: 查看数据库表的底层大小以及表结构，同样可以从information_schema.tables表中获得底层表的信息。
8、show [global|session]status:可以查看mysql服务器当前内部状态信息。可以帮助却行mysql服务器的负载的各种指标。默认是session。同information_schema.global_status和information_schema.session_status
9、show [global|session] variables ：查看当前mysql系统变量的值，其中一些值能影响到sql语句的执行方式。同information_schema.global_variables和information_schema.session_variables;
10、information_schema:包含的表的数量和mysql的版本有关系。
Ⅸ 北大青鸟设计培训：mysql数据库的优化方法
我们都知道，服务器数据库的开发一般都是通过java或者是PHP语言来编程实现的，而为了提高我们数据库的运行速度和效率，数据库优化也成为了我们每日的工作重点，今天，昌平IT培训http://www.kmbdqn.cn/就一起来了解一下mysql服务器数据库的优化方法。
为什么要了解索引真实案例案例一：大学有段时间学习爬虫，爬取了知乎300w用户答题数据，存储到mysql数据中。
那时不了解索引，一条简单的“根据用户名搜索全部回答的sql“需要执行半分钟左右，完全满足不了正常的使用。
案例二：近线上应用的数据库频频出现多条慢sql风险提示，而工作以来，对数据库优化方面所知甚少。
例如一个用户数据页面需要执行很多次数据库查询，性能很慢，通过增加超时时间勉强可以访问，但是性能上需要优化。
索引的优点合适的索引，可以大大减小mysql服务器扫描的数据量，避免内存排序和临时表，提高应用程序的查询性能。
索引的类型mysql数据中有多种索引类型，primarykey，unique，normal，但底层存储的数据结构都是BTREE;有些存储引擎还提供hash索引，全文索引。
BTREE是常见的优化要面对的索引结构，都是基于BTREE的讨论。
B-TREE查询数据简单暴力的方式是遍历所有记录;如果数据不重复，就可以通过组织成一颗排序二叉树，通过二分查找算法来查询，大大提高查询性能。
而BTREE是一种更强大的排序树，支持多个分支，高度更低，数据的插入、删除、更新更快。
现代数据库的索引文件和文件系统的文件块都被组织成BTREE。
btree的每个节点都包含有key，data和只想子节点指针。
btree有度的概念d>=1。
假设btree的度为d，则每个内部节点可以有n=[d+1，2d+1)个key，n+1个子节点指针。
树的大高度为h=Logb[(N+1)/2]。
索引和文件系统中，B-TREE的节点常设计成接近一个内存页大小(也是磁盘扇区大小)，且树的度非常大。
这样磁盘I/O的次数，就等于树的高度h。
假设b=100，一百万个节点的树，h将只有3层。
即，只有3次磁盘I/O就可以查找完毕，性能非常高。
索引查询建立索引后，合适的查询语句才能大发挥索引的优势。
另外，由于查询优化器可以解析客户端的sql语句，会调整sql的查询语句的条件顺序去匹配合适的索引。