mysql 存储过程执行太慢怎么优化

1.当我们请求mysql服务器的时候,MySQL前端会有一个监听,请求到了之后,服务器得到相关的SQL语句,执行之前(虚线部分为执行),还会做权限的判断

创新互联建站专注于龙湾企业网站建设,响应式网站建设,商城网站制作。龙湾网站建设公司,为龙湾等地区提供建站服务。全流程按需求定制制作，专业设计，全程项目跟踪，创新互联建站专业和态度为您提供的服务

2.通过权限之后,SQL就到MySQL内部,他会在查询缓存中,看该SQL有没有执行过,如果有查询过,则把缓存结果返回,说明在MySQL内部,也有一个查询缓存.但是这个查询缓存,默认是不开启的,这个查询缓存,和我们的Hibernate，Mybatis的查询缓存是一样的,因为查询缓存要求SQL和参数都要一样,所以这个命中率是非常低的（没什么卵用的意思）。

3.如果我们没有开启查询缓存,或者缓存中没有找到对应的结果,那么就到了解析器,解析器主要对SQL语法进行解析

4.解析结束后就变成一颗解析树,这个解析树其实在Hibernate里面也是有的,大家回忆一下,在以前做过Hibernate项目的时候,是不是有个一个antlr.jar。这个就是专门做语法解析的工具.因为在Hibernate里面有HQL，它就是通过这个工具转换成SQL的,我们编程语言之所以有很多规范、语法,其实就是为了便于这个解析器解析,这个学过编译原理的应该知道.

5.得到解析树之后,不能马上执行,这还需要对这棵树进行预处理,也就是说,这棵树,我没有经过任何优化的树,预处理器会这这棵树进行一些预处理,比如常量放在什么地方,如果有计算的东西,把计算的结果算出来等等...

6.预处理完毕之后,此时得到一棵比较规范的树,这棵树就是要拿去马上做执行的树,比起之前的那棵树,这棵得到了一些优化

7.查询优化器，是MySQL里面最关键的东西,我们写任何一条SQL,比如SELECT * FROM USER WHERE USERNAME = toby AND PASSWORD = 1,它会怎么去执行?它是先执行username = toby还是password = 1?每一条SQL的执行顺序查询优化器就是根据MySQL对数据统计表的一些信息,比如索引,比如表一共有多少数据,MySQL都是有缓存起来的,在真正执行SQL之前,他会根据自己的这些数据,进行一个综合的判定,判断这一次在多种执行方式里面,到底选哪一种执行方式,可能运行的最快.这一步是MySQL性能中,最关键的核心点,也是我们的优化原则.我们平时所讲的优化SQL,其实说白了,就是想让查询优化器,按照我们的想法,帮我们选择最优的执行方案,因为我们比MySQL更懂我们的数据.MySQL看数据,仅仅只是自己收集到的信息,这些信息可能是不准确的,MySQL根据这些信息选了一个它自认为最优的方案,但是这个方案可能和我们想象的不一样.

8.这里的查询执行计划,也就是MySQL查询中的执行计划,比如要先执行username = toby还是password = 1

9.这个执行计划会传给查询执行引擎,执行引擎选择存储引擎来执行这一份传过来的计划,到磁盘中的文件中去查询,这个时候重点来了,影响这个查询性能最根本的原因是什么?就是硬盘的机械运动,也就是我们平时熟悉的IO,所以一条查询语句是快还是慢,就是根据这个时间的IO来确定的.那怎么执行IO又是什么来确定的?就是传过来的这一份执行计划.(优化就是制定一个我们认为最快的执行方案,最节省IO,和执行最快)

10.如果开了查询缓存,则返回结果给客户端,并且查询缓存也放一份。

mysql怎么快熟存储多条数据

我以前做过一个mysql的项目，需要设计一个快速上载的机制。最后的解决办法是利用了mysql的预处理语句的特性实现的。mysql的预处理语句支持多行数据的预处理，即 insert into (columnName,columnName,...) values(?,?,...)(?,?,..)...。这样你在绑定输入参数的时候可以在程序里将整张表的数据都绑定好然后调用一次执行就能将整张表的数据插入，比用mysql_query一行一行插入省的几倍的时间。不过你一次发到mysql服务器端的数据多的情况下，要设置my.ini文件下的一个配置项，把服务器允许一次发送的数据包的大小调大就行。

MySQL 如何存储大数据

行格式为Compact是如何存储大数据的：

[vb] view plain copy

mysql select version();

+-----------+

| version() |

+-----------+

| 5.1.73    |

+-----------+

1 row in set (0.01 sec)

mysql show table status like 'row'\G;

*************************** 1. row ***************************

Name: row

Engine: InnoDB

Version: 10

Row_format: Compact

Rows: 1

Avg_row_length: 81920

Data_length: 81920

Max_data_length: 0

Index_length: 0

Data_free: 0

Auto_increment: NULL

Create_time: 2017-01-04 21:46:02

Update_time: NULL

Check_time: NULL

Collation: latin1_swedish_ci

Checksum: NULL

Create_options:

Comment:

1 row in set (0.00 sec)

我们建立一张测试表，插入数据：

[html] view plain copy

CREATE TABLE `row` (

`content` varchar(65532) NOT NULL DEFAULT ''

) ENGINE=InnoDB DEFAULT CHARSET=latin1

mysql insert into row(content) select repeat('a',65532);

Query OK, 1 row affected (0.03 sec)

Records: 1  Duplicates: 0  Warnings: 0

我们使用 py_innodb_page_info.py 工具来查看表中的页分布：

[vb] view plain copy

[root@localhost mysql]# python py_innodb_page_info.py -v com/row.ibd

page offset 00000000, page type File Space Header

page offset 00000001, page type Insert Buffer Bitmap

page offset 00000002, page type File Segment inode

page offset 00000003, page type B-tree Node, page level 0000

page offset 00000004, page type Uncompressed BLOB Page

page offset 00000005, page type Uncompressed BLOB Page

page offset 00000006, page type Uncompressed BLOB Page

page offset 00000007, page type Uncompressed BLOB Page

Total number of page: 8:

Insert Buffer Bitmap: 1

Uncompressed BLOB Page: 4

File Space Header: 1

B-tree Node: 1

File Segment inode: 1

可以看出，第4页的 B-tree Node, page level 0000 格式为数据页，存放着MySQL的行数据。 Uncompressed BLOB Page 可以理解为MySQL存放大数据的地方，暂且叫作外部存储页。Compact格式没有将大数据全部放在数据页中，而是将一部分数据放在了外部存储页中。那么，是全部数据在外部存储页中，还是一部分数据。假如是一部分数据，这一部分是多少呢？

我们使用 hexdump -Cv row.ibd 查看一下数据页 B-tree Node, page level 0000 ，也就是第4页：

[vb] view plain copy

3073 0000c000  8c 25 17 57 00 00 00 03  ff ff ff ff ff ff ff ff  |.%.W....????????|

3074 0000c010  00 00 00 00 00 07 3a b8  45 bf 00 00 00 00 00 00  |......:?E?......|

3075 0000c020  00 00 00 00 00 02 00 02  03 a6 80 03 00 00 00 00  |.........?......|

3076 0000c030  00 7f 00 05 00 00 00 01  00 00 00 00 00 00 00 00  |................|

3077 0000c040  00 00 00 00 00 00 00 00  00 13 00 00 00 02 00 00  |................|

3078 0000c050  00 02 00 f2 00 00 00 02  00 00 00 02 00 32 01 00  |...?.........2..|

3079 0000c060  02 00 1c 69 6e 66 69 6d  75 6d 00 02 00 0b 00 00  |...infimum......|

3080 0000c070  73 75 70 72 65 6d 75 6d  14 c3 00 00 10 ff f1 00  |supremum.?...??.|

3081 0000c080  00 00 00 04 03 00 00 00  00 13 12 80 00 00 00 2d  |...............-|

3082 0000c090  01 10 61 61 61 61 61 61  61 61 61 61 61 61 61 61  |..aaaaaaaaaaaaaa|

3083 0000c0a0  61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  |aaaaaaaaaaaaaaaa|

3084 0000c0b0  61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  |aaaaaaaaaaaaaaaa|

3085 0000c0c0  61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  |aaaaaaaaaaaaaaaa|

....

....

3128 0000c370  61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  |aaaaaaaaaaaaaaaa|

3129 0000c380  61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  |aaaaaaaaaaaaaaaa|

3130 0000c390  61 61 00 00 00 02 00 00  00 04 00 00 00 26 00 00  |aa.............|

3131 0000c3a0  00 00 00 00 fc fc 00 00  00 00 00 00 00 00 00 00  |....??..........|

3132 0000c3b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

3133 0000c3c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

3134 0000c3d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

...

...

4093 0000ffc0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

4094 0000ffd0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

4095 0000ffe0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

4096 0000fff0  00 00 00 00 00 70 00 63  01 a1 6c 2b 00 07 3a b8  |.....p.c.?l+..:?|

mysql 存储过程的执行速度不快

大致看了下，用了2个游标，2个临时表，n个insert、update操作。。。

游标是不推荐使用的，慢，如果真得用，那还是放到后台php去循环好。

主要是没弄懂你要做的操作和逻辑，不然mysql用join来操作，把游标去掉，换成mysql自己每行去遍历，估计也就毫秒级。（估计你目前整个表的数据也就几万而已）

利用MySQL数据库如何解决大数据量存储问题？

照你的需求来看，可以有两种方式，一种是分表，另一种是分区 首先是分表，就像你自己所说的，可以按月分表，可以按用户ID分表等等，至于采用哪种方式分表，要看你的业务逻辑了，分表不好的地方就是查询有时候需要跨多个表。 然后是分区，分区可以将表分离在若干不同的表空间上，用分而治之的方法来支撑无限膨胀的大表，给大表在物理一级的可管理性。将大表分割成较小的分区可以改善表的维护、备份、恢复、事务及查询性能。分区的好处是分区的优点： 1 增强可用性：如果表的一个分区由于系统故障而不能使用，表的其余好的分区仍然可以使用； 2 减少关闭时间：如果系统故障只影响表的一部分分区，那么只有这部分分区需要修复，故能比整个大表修复花的时间更少； 3 维护轻松：如果需要重建表，独立管理每个分区比管理单个大表要轻松得多； 4 均衡I/O:可以把表的不同分区分配到不同的磁盘来平衡I/O改善性能； 5 改善性能：对大表的查询、增加、修改等操作可以分解到表的不同分区来并行执行，可使运行速度更快； 6 分区对用户透明，最终用户感觉不到分区的存在。

mysql 比文件存储哪个快

mysql更快。

1、直接读文件相比数据库查询效率更胜一筹，而且文中还没算上连接和断开的时间。

2、一次读取的内容越大，直接读文件的优势会越明显（读文件时间都是小幅增长，这跟文件存储的连续性和簇大小等有关系），这个结果恰恰跟书生预料的相反，说明MYSQL对更大文件读取可能又附加了某些操作（两次时间增长了近30%），如果只是单纯的赋值转换应该是差异偏小才对。

3、写文件和INSERT几乎不用测试就可以推测出，数据库效率只会更差。

4、很小的配置文件如果不需要使用到数据库特性，更加适合放到独立文件里存取，无需单独创建数据表或记录，很大的文件比如图片、音乐等采用文件存储更为方便，只把路径或缩略图等索引信息放到数据库里更合理一些。

5、PHP上如果只是读文件，file_get_contents比fopen、fclose更有效率，不包括判断存在这个函数时间会少3秒左右。

6、fetch_row和fetch_object应该是从fetch_array转换而来的，书生没看过PHP的源码，单从执行上就可以说明fetch_array效率更高，这跟网上的说法似乎相反。

实 际上在做这个试验之前，从个人经验判断就有了大概的结果，测试完成后则有种豁然开朗的感觉。假定在程序效率和关键过程相当且不计入缓存等措施的条件下，读 写任何类型的数据都没有直接操作文件来的快，不论MSYQL过程如何，最后都要到磁盘上去读这个“文件”（记录存储区等效），所以当然这一切的前提是只读 内容，无关任何排序或查找操作。

MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，属于 Oracle 旗下产品。MySQL 是最流行的关系型数据库管理系统之一，在 WEB 应用方面，MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件之一。

MySQL是一种关系型数据库管理系统，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。

MySQL所使用的 SQL 语言是用于访问数据库的最常用标准化语言。MySQL 软件采用了双授权政策，分为社区版和商业版，由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，一般中小型网站的开发都选择 MySQL 作为网站数据库。

分享文章：mysql怎么存储快点 数据存储mysql的应用技巧
当前路径：http://lswzjz.com/article/dodoece.html