使用
创新互联是一家集网站建设,永川企业网站建设,永川品牌网站建设,网站定制,永川网站建设报价,网络营销,网络优化,永川网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。
unbuffered
cursor
可以避免内存问题。
cursor
默认使用
buffered
模式。这种模式会把所有结果集返回并载入内存。如果结果集很大的话，内存会爆。
unbuffered
cursor
是每次只将下一行结果返回，内存占用很小。不过这种模式缺点很多，所以没有作为默认的模式。
内存表有大小限制，内存文件超过 my.ini 中设置以后，会自动转换部分到硬盘。内存表所占内存以固定的大小分配空间，即使一个表中只有一条记录，也可能占几M空间。内存表是有大小限制的，在 my.ini 中可以设置，当内存大小达到限制时，可能会报错：#1114: The table ‘XXX’ is full 。上面是我实际遭遇到的，但是 my.ini 中有下面这段：
# Maximum size for internal (in-memory) temporary tables. If a table
# grows larger than this value, it is automatically converted to disk
# based table This limitation is for a single table. There can be many
# of them.
tmp_table_size=13M
我们仍然使用两个会话，一个会话 run，用于运行主 SQL；另一个会话 ps，用于进行 performance_schema 的观察：
主会话线程号为 29，
将 performance_schema 中的统计量重置，
临时表的表大小限制取决于参数 tmp_table_size 和 max_heap_table_size 中较小者，我们实验中以设置 max_heap_table_size 为例。
我们将会话级别的临时表大小设置为 2M（小于上次实验中临时表使用的空间），执行使用临时表的 SQL：
查看内存的分配记录：
会发现内存分配略大于 2M，我们猜测临时表会比配置略多一点消耗，可以忽略。
查看语句的特征值：
可以看到语句使用了一次需要落磁盘的临时表。
那么这张临时表用了多少的磁盘呢？
我们开启 performance_schema 中 waits 相关的统计项：
重做实验，略过。
再查看 performance_schema 的统计值：
可以看到几个现象：
1. 临时表空间被写入了 7.92MiB 的数据。
2. 这些数据是语句写入后，慢慢逐渐写入的。
来看看这些写入操作的特征，该方法我们在 实验 03 使用过：
可以看到写入的线程是 page_clean_thread，是一个刷脏操作，这样就能理解数据为什么是慢慢写入的。
也可以看到每个 IO 操作的大小是 16K，也就是刷数据页的操作。
结论：
我们可以看到，
1. MySQL 会基本遵守 max_heap_table_size 的设定，在内存不够用时，直接将表转到磁盘上存储。
2. 由于引擎不同（内存中表引擎为 heap，磁盘中表引擎则跟随 internal_tmp_disk_storage_engine 的配置），本次实验写磁盘的数据量和 实验 05 中使用内存的数据量不同。
3. 如果临时表要使用磁盘，表引擎配置为 InnoDB，那么即使临时表在一个时间很短的 SQL 中使用，且使用后即释放，释放后也会刷脏页到磁盘中，消耗部分 IO。
作用是内存的大小可通过My.cnf中的max_heap_table_size指定。
MySQL的授权系统是通过MySQL数据库中的五个表来实现的，这些表有user、db、host、tables_priv和columns_priv。这些表的用途各有不同，但是有一点是一致的，那就是都能够检验用户要做的事情是否为被允许的。
扩展资料
mysql数据库表包含的授权信息
1、user：用户帐户，全局权限和其他非特权列
2、db：数据库级权限
3、tables_priv：表级特权
4、columns_priv：列级权限
5、procs_priv：存储过程和功能特权
6、proxies_priv：代理用户权限
Linux 进程通过 C 标准库中的内存分配函数 malloc 向系统申请内存，但是到真正与内核交互之间，其实还隔了一层，即内存分配管理器(memory allocator)。常见的内存分配器包括：ptmalloc(Glibc)、tcmalloc(Google)、jemalloc(FreeBSD)。MySQL 默认使用的是 glibc 的 ptmalloc 作为内存分配器。
内存分配器采用的是内存池的管理方式，处在用户程序层和内核层之间，它响应用户的分配请求，向操作系统申请内存，然后将其返回给用户程序。
为了保持高效的分配，分配器通常会预先向操作系统申请一块内存，当用户程序申请和释放内存的时候，分配器会将这些内存管理起来，并通过一些算法策略来判断是否将其返回给操作系统。这样做的最大好处就是可以避免用户程序频繁的调用系统来进行内存分配，使用户程序在内存使用上更加高效快捷。
关于 ptmalloc 的内存分配原理，个人也不是非常了解，这里就不班门弄斧了，有兴趣的同学可以去看下华庭的《glibc 内存管理 ptmalloc 源代码分析》【文末链接】。
关于如何选择这三种内存分配器，网上资料大多都是推荐摒弃 glibc 原生的 ptmalloc，而改用 jemalloc 或者 tcmalloc 作为默认分配器。因为 ptmalloc 的主要问题其实是内存浪费、内存碎片、以及加锁导致的性能问题，而 jemalloc 与 tcmalloc 对于内存碎片、多线程处理优化的更好。
目前 jemalloc 应用于 Firefox、FaceBook 等，并且是 MariaDB、Redis、Tengine 默认推荐的内存分配器，而 tcmalloc 则应用于 WebKit、Chrome 等。
说一下临时表，仅供参考。
MySQL 需要创建隐式临时表来解决某些类型的查询。往往查询的排序阶段需要依赖临时表。例如，当您使用 GROUP BY，ORDER BY 或DISTINCT 时。这样的查询分两个阶段执行：首先是收集数据并将它们放入临时表中，然后是在临时表上执行排序。
对于某些 UNION 语句，不能合并的 VIEW，子查询时用到派生表，多表 UPDATE 以及其他一些情况，还需要使用临时表。如果临时表很小，可以到内存中创建，否则它将在磁盘上创建。MySQL 在内存中创建了一个表，如果它变得太大，就会被转换为磁盘上存储。内存临时表的最大值由 tmp_table_size 或 max_heap_table_size 值定义，以较小者为准。MySQL 5.7 中的默认大小为 16MB。如果运行查询的数据量较大，或者尚未查询优化，则可以增加该值。设置阈值时，请考虑可用的 RAM 大小以及峰值期间的并发连接数。你无法无限期地增加变量，因为在某些时候你需要让 MySQL 使用磁盘上的临时表。
注意：如果涉及的表具有 TEXT 或 BLOB 列，则即使大小小于配置的阈值，也会在磁盘上创建临时表。