7.高性能MySQL --- MySQL 高级特性

7.MySQL 高级特性7.1.分区表对用户来说，分区表是一个独立的逻辑表，是由底层多个物理子表组成的。实现分区的代码实际上是对一组底层表的句柄对象的封装。对分区表的请求，都会通过句柄对象转化为对存储引擎的接口调用。所以分区对于sql层来说是一个完全封装底层实现的黑盒子，对应用是透明的，但是从底层的文件系统来看就很容易发现，每一个分区表都有一个使用#分割命名的表文件。mysql 实现分区表的方式---对底层表的封装---意味着索引也是按照分区的子表定义的，没有全局索引。mysql在创建表时使用 partition by 子句定义每个分区存放的数据。在执行查询的时候，优化器会根据分区定义过滤那些没有我们需要数据的分区，这样查询就无需扫描所有分区---只需要查找包含数据的分区就可以了。分区的一个主要目的是将数据按照一个较粗的粒度分在不同的表中。这样做可以将相关的表放在一起，另外，如果想一次性删除整个分区的数据也会变得方便。分区的场景：    1.表非常大以至于无法全部都放在内存中，或者只在表的最后部分有热点数据，其他均是历史数据。2.分区表的数据更容易维护。例如，想批量删除大量数据可以使用清楚整个分区的方式。另外，还可以对一个独立的分区进行优化，检查，修复等操作3.分区表的数据可以分布在不同的物理设备上，从而高效的利用多个硬件设备4.可以使用分区表来避免某些特殊的瓶颈，如InnoDB的单个索引的互斥访问，ext3文件系统的inode锁竞争5.如果需要，还可以备份和恢复独立的分区，这在非常大的数据的场景下效果非常好限制：1.一个表最多1024个分区2.在mysql5.1中，分区表达式必须是整数，或者返回整数的表达式。3.如果分区字段中有主键或者唯一索引的列，那么所有主键列和唯一索引都必须包含进来4.分区表中无法使用外键约束7.1.1 分区表的原理分区表由多个相关的底层表实现，这些底层表也是由句柄对象表示，所以我们也可以直接访问各个分区。存储引擎管理分区的各个底层表和管理普通表一样，(所有的底层表都必须使用相同的存储引擎)，分区表的索引只是在各个底层表上各自加上一个完全相同的索引。从存储引擎的角度看，底层表和一个普通的表没有任何不同，存储引擎也无需知道这是一个普通表还是一个分区表。分区表上的操作按照如下的操作逻辑进行：1.select 查询当查询一个分区的时候，分区层先打开并锁住所有的底层表，优化器先判断是否可以过滤部分分区，然后再调用对应的存储引擎接口并访问各个分区的数据。2.insert 操作当写入一条数据的时候，分区层先打开并锁住所有的底层表，然后确定哪个分区接收这条记录，再将记录写入对于的底层表3.delete 操作当删除一条记录的时候，分区层先打开并锁住所有的底层表，然后确定数据对于哪个分区，最后对相应的底层表进行删除操作4.update 操作当更新一条记录的时候，分区层先打开并锁住所有的底层表，mysql先确定需要更新的记录在哪个分区，然后取出数据并更新，再判断更新后的数据应该放在哪个分区，最后对底层表进行写入操作，并对原有的数据所在的底层表进行删除。虽然每个操作都会 '打开并锁住所有的底层表', 但这并不是说分区表在处理过程中是锁住全表的。如果存储引擎自己能够实现行级锁，如InnoDB，则会在分区层释放对于的表锁。7.1.2 分区表的类型mysql支持多种分区类型。最多的是根据范围进行分区，每个分区存储落在某个范围的记录，分区表达式可以是列，也可以是包含列的表达式。create table 表名(...)engne=InnoDB partition by range(year(order_date)) (parttion p_2010 values less than (2010),parttion p_2011 values less than (2011),parttion p_2012 values less than (2012),parttion p_catchall values less than maxvalue,);partition 分区子句中可以使用各种函数。但是有一个要求，表达式返回的值必须是一个整数，且不能是一个常数。这里我们使用year()函数，根据时间进行分割是比较常见的。mysql 还支持键值，哈希和列表分区，这其中还有支持子分区的，不过在生成环境中很少见。在mysql5.5中还可以使用range columns 类型的分区，这样即使是基于时间的分区也无需再将其转化为一个整数。类似于前面按时间分区的InnoDB表，系统通过子分区可降低索引的互斥访问的竞争。最近一年的分区的数据会被频繁的访问，这会导致大量的互斥竞争。使用哈希子分区可以将数据切成多个小片，大大降低互斥量的竞争问题。其他分区技术：1.根据进行分区，来减少InnoDB的互斥量竞争2.使用数学模型进行分区，然后将数据轮询放入不同的分区。3.假设表有一个自增的主键列id,希望根据时间将最近的热点数据集中存放。那么必须将时间戳包含在主键中才行，而这和主键本身的含义是矛盾的。7.1.3 如何使用分区表因为数据量巨大，肯定不能在每次查询的时候都扫描全表。考虑到索引在空间和维护上的消耗，也不希望使用索引。即使真的使用索引，你会发现数据并不是按照想要的方式聚集的，而且会有大量的碎片产生，最终会导致一个查询产生成千上万的随机IO，应用程序随着僵死。这个时候只有2种选择：让所有的查询都只在数据表上做顺序扫描，或者将数据表和索引全部都缓存在内存里。在数据量超大的时候，B-Tree索引就无法起作用了。除非是索引覆盖，否则数据库服务器需要根据索引扫描的结果回表，查询所有符合条件的记录，如果数据量巨大，这将会产生大量随机IO，随着数据库的响应时间将大到不可接受的程序。另外，维护索引(磁盘空间，IO操作)的代价也非常高。这是分区要做的事情。理解分区时还可以将其当做索引的最初形态，以非常小的代价定位到需要的数据再哪一片'区域'。在此区域中，你可以做顺序扫描，可以建索引，还可以将数据缓存到内存中，等等。因为分区无需额外的数据结构记录每个分区有哪些数据---分区不需要精确定位每条数据的位置，也就无需额外的数据结构---所以其代价非常低。只需要一个简单的表达式就可以表达每个分区存放的是什么数据。为了保证大数据量的可扩展性，一般有如下2个策略：1.全量扫描数据，不要索引可以使用简单的分区方式存放表，不要任何索引，根据分区的规则大致定位需要的数据位置。只要能够使用where条件，将需要的数据限制在少数分区中，则效率是很高的。当然，也需要做一些简单的运算保证查询的响应时间能够满足需求。使用该策略假设不用将数据完全放入内存中，同时还假设需要的数据全部在磁盘上，因为内存相对小，数据很快被排出内存，所以缓存起不了任何作用。这个策略适用于以正常方式访问大量数据的时候。警告：必须将查询需要扫描的分区个数限制在一个很小的数量。2.索引数据，分离热点如果数据有明显的'热点'，而且除了这部分数据，其他数据很少被访问到，那么可以将这部分热点数据单独放在一个分区中，让这个分区的数据能够有机会都缓存到内存中。这样查询就可以只访问一个很小的分区表，能够使用索引，也能够有效的使用缓存。7.1.4 什么情况下会出问题上面的策略都基于两个非常重要的假设：1.查询都能够过滤掉很多额外的分区；2.分区本身不会带来很多额外的代价。而事实证明，这2个假设在某些场景下会有问题：1.null值会使得分区过滤无效分区的表达式的值可以是null:第一个分区是一个特殊的分区，假设按照 partition by year(order_date)分区，那么所有的order_date 为null或者一个非法值的时候，记录会被存到第一个分区。现在假设有下面的查询： where order between '2012-0101' and '2012-01-31'。实际上，mysql会检查2个分区，而不是之前猜想的一个：它会检查 2012这个分区，同时它还会检查这个表的第一个分区。检查第一个分区是因为year()函数在接收到非法值的时候可能会返回null值，那么这个范围的值可能会返回null而被存放到了第一个分区了。如果第一个分区非常大，特别是当使用'全量扫描数据，不要任何索引'的策略时，代价会非常大。而且扫描2个分区来查找列也不是我们使用分区的初衷。为了避免这种情况，可以创建一个'无用'的第一个分区，例如，上面的例子中可以使用 partition p_nulls values less than (0) 来创建第一个分区。如果插入表中的数据都是有效的，那么第一个分区就是空的，这样即使需要检测到第一个分区，代价也是非常小的。在mysql5.5中就不需要这个优化技巧了，因为可以直接使用列本身而不是基于列的函数函数进行分区： partition by range columns(order_date);2.分区列和索引列不匹配如果定义的索引列和分区列不匹配，会导致无法进行分区过滤。假设在列a上定义了索引，而在列b上进行了分区。因为每个分区都有其独立的索引，所以扫描列b上的索引就需要扫描每一个分区对应的索引。如果每个分区内对应的索引的非叶子节点都在内存中，那么扫描的速度还可以接受，但如果能跳过某些分区索引当然会更好。要避免这个问题，应该避免建立和分区列不匹配的索引，除非查询中还同时包含了可以过滤分区的条件。听起来避免这个问题很简单，不过有时候也会遇到一些问题。例如，在一个关联查询中，分区表在关联顺序中是第二个表，并且关联表使用的索引和分区条件不匹配。那么关联时针对第一个表符合条件的每一行，都需要访问并搜索第二个表的所有分区。3.选择分区的成本可能很高分区有很多类型，不同类型的分区的实现方式也不同，所以他们的性能也各不相同。尤其是分区范围，对于回答'这一行属于哪个分区'，'这些符合查询条件的行在哪些分区'这样的问题的成本可能会很高，因为服务器需要扫描所有的分区定义的列表来找到正确答案。随着分区数的增长，成本也会越来越高。按行写入大量数据的时候。每写入一行数据到范围分区的表时，都需要扫描分区定义列表来找到合适的目标分区。可以通过限制分区的数量来缓解此问题，根据经验，100个左右的分区是没有问题的。其他类型的分区，比如键分区和哈希分区，则没有这个问题。4.打开并锁住所有底层表的成本可能很高当查询访问分区表的时候，mysql需要打开并锁住所有的底层表，这是分区的另外一个开销。这个操作在分区过滤之前发生，所以无法通过分区过滤来降低此开销，并且该开销也和分区类型无关，会影响所有的查询。这一点对一些本身操作很快的查询，比如根据主键查找行，会带来明显的额外开销。可以用批量操作的方式来降低单个操作的此类开销。例如，使用批量插入或者 load data infile,一次性删除多行数据等。5.维护分区的成本可能很高某些分区维护的操作的速度可能非常快，例如新增和删除分区。而有些操作，例如重组分区或者类似 alter 语句的操作：这类操作需要复制数据。重组分区的原理和alter类型，先创建一个临时的分区，然后将数据复制到其中，最后再删除原分区。分区的其他限制：1.所有的分区都必须使用相同的存储引擎2.分区函数中使用的函数和表达式也有一些限制3.某些存储引擎不支持分区4.对于MyISAM表，使用分区，不能再使用 load index into cache 等操作5.对于MyISAM表，使用分区表时需要打开更多的文件描述符。虽然看起来是一个表，其实背后有很多独立的分区，每一个分区对于存储引擎来说都是一个独立的表。这样即使分区表只占用一个表缓存条目，文件描述符还是需要多个。因此，即使已经配置了合适的表缓存，以确保不会超过系统的单个进程可以打开的文件描述符的个数，但对于分区表而言，还是会出现超过文件描述符限制的问题。alter table exchange partition;7.1.5 查询优化分区的最大优点是优化器可以根据分区函数来过滤一些分区。根据粗粒度索引的优势，通过分区过滤通常可以让查询扫描更少的数据。所以，对于访问分区表来说，很重要的一点是要在 where 条件中带入分区列，有时候即使看似多余也要带上，这样就可以让优化器能够过滤掉无需访问的分区。如果没有这样的话，mysql就需要让对应的存储引擎访问这个表的所有分区，如果表非常大的话，就可能会很慢。使用 explain partition 可以观察优化器是否执行了分区过滤，explain partitions sql ...mysql 只能根据使用分区函数的列本身进行比较时才能过滤分区，而不能根据表达式的值去过滤分区，即使这个表达式就是分区函数也不行。这就和查询中使用独立的列才能使用索引的道理是一样的。一个很重要的原则是：即便在创建分区时可以使用表达式，但是在查询时却只能根据列来过滤分区。7.1.6 合并表合并表是一种早期的，简单的分区实现，和分区表相比有一些不同的限制，并且缺乏优化。分区表严格来说是一个逻辑上的概念，用户无法访问底层的各个分区，对用户来说分区是透明的。但是合并表允许用户单独访问各个子表。合并表相当于一个容器，里面包含了多个真实表。可以在create table 中使用一种特别的union语法来指定哪些是真是表。如：create table t1(a int not null primary key)engine=MyISAM;create table t2(a int not null primary key)engine=MyISAM;insert into t1(a) values(1),(2);insert into t2(a) values(1),(2);create table mrg(a int not null primary key)engine=MERGE union(t1,t2) insert_method=last;select * from mrg;注意，这里最后创建是合并表和前面的各个真实表字段完全一样，在合并表中有的索引各个真实子表也有，这是创建合并表的前提条件。另外还需注意，各个子表在对应的列上都有主键限制，但是最终的合并表中仍然出现了重复值，这是合并表的另外一个不足：合并表中的每一个子表的行为和表定义都是相同的，但是合并表在全局上并不受这些条件限制。这里的语法 insert_method=last 告诉mysql,将所有的insert 语句都发送给最后一个表。指定first，或者last关键字是唯一可以控制行插入到合并表的哪个子表的方式。

绑定变量：
客户端向服务器发送一个SQL原型，服务端收到这个SQL后，解析并储存这个SQL语句的执行部分。
返回给客户端一个 SQL 句柄。以后每次执行这类查询，客户端都指定执行这个句柄。优点：服务器只解析一次SQL;服务端的某些优化器只需要执行一次，因为它会缓存一部分执行计划；以二进制的形式发送参数和句柄，比每次都发送ASCII码更有效率，一个二进制日期只要3个字节，ASCII需要10个字节。最大的节省还是来自blog和text，绑定变量的形式可以分块传输，无需一次性传输。二进制协议在客户端也可以节省很多内存，减少网络开销。还节省了数据从存储原始格式转换成文本格式的开销;仅仅是参数，而不是整个查询语句发送到服务器，所以网络开销会更小;MySQL 在存储参数时，直接将其放入缓存，不需要在内存中多次复制；更安全，无需在应用程序中处理转义，一则更简单，二则大大减少了SQL注入的风险。

字符集客户端 ： character_set_clientconnection : character_set_connection返回：character_set_resultsset names utf8 // 3个都变了校对规则：cs( case sensitive )ci( case insensitive )bin( 二进制存储，不区分大小 ) 多字节字段中，用 char_length() 统计比较准确}’

分区表场景：
1.表太大，只在最后又表的热点数据，其余都是历史数据
2.分区表易于维护，可批量删除
3.分数区表数据可以分布在不同物理设备上
4.使用分区表避免某些瓶颈(InnoDB单个索引的互斥访问等)
5.可以恢复和备份单独的分区分区表限制：
1.一个表只能有 1024 个分区
2.分区表达式必须是整数，或者返回整数的表达式
3.分区字段中有主键或者唯一索引的列，那么所有主键和唯一索引必须包含进来
4.分区表无法使用外键约束

外键约束：使用外键是有成本的。比如外键通常要求在每次修改数据时都要在另外一张表中执行一次查找操作。如果外键列的选择性很低，则会导致一个非常大且选择性很低的索引。某些场景下，外键会提升一些性能。如果想确保两个相关表始终有一致的数据，那么使用外键比在应用程序中检查一致性的性能要高的多。此外，外键在相关的删除和更新上，也比在应用中维护要更高效，不过，外键的维护操作是逐行进行的，所以这样的更新会比批量删除和更新要慢些。7.4 在MySQL内部存储代码触发器 : 可以让你在执行 insert,update和delete 的时候，执行一些特定的操作。可以在MySQL中指定是在 sql 语句之前触发还是之后触发。1.对每个表的每一个事件，最多只能定义一个触发器。2.MySQL只支持 '基于行的触发'存储过程函数 : 存储过程只能用sql来编写，而 UDF 没有这个限制。事件 : 类似于Linux的定时任务，指定mysql在某个时候执行一段sql代码，或者每隔一个时间执行一段sql代码.7.6 绑定变量当创建一个绑定变量sql时，客户端向服务器发送了一个sql语句的原型。服务器收到这个sql语句框架后，解析并储存这个sql语句的部分执行计划，返回给客户端一个sql语句的处理句柄。以后每次执行这类查询，客户端都指定使用这个句柄。绑定变量的sql，使用问号标记可以接收参数的位置，当真正需要执行具体查询的时候，则使用具体的值代替这些问号。优点：1.服务器只解析一次SQL;2.服务端的某些优化器只需要执行一次，因为它会缓存一部分执行计划；3.以二进制的形式发送参数和句柄，比每次都发送ASCII码更有效率，一个二进制日期只要3个字节，ASCII需要10个字节。最大的节省还是来自blog和text，绑定变量的形式可以分块传输，无需一次性传输。二进制协议在客户端也可以节省很多内存，减少网络开销。还节省了数据从存储原始格式转换成文本格式的开销;4.仅仅是参数，而不是整个查询语句发送到服务器，所以网络开销会更小;5.MySQL 在存储参数时，直接将其放入缓存，不需要在内存中多次复制；6.更安全，无需在应用程序中处理转义，一则更简单，二则大大减少了SQL注入的风险。也只有使用绑定变量的时候才使用二进制传输协议。如果使用普通的 mysql_query() 接口则不会使用二进制传输协议。限制：1.绑定变量是会话级别的，所以连接之间不能共用绑定变量句柄。同样的，一旦连接断开，则原来的句柄也不能再使用了。2.mysql5.1 之前，绑定变量的sql是不能使用查询缓存的3.并不是所有的时候使用绑定变量都能获得良好的性能。如果只是执行一次sql，那么使用绑定变量方式无疑比直接执行一次额外的准备阶段消耗，而且还需要一次网络的开销4.当前版本下，还不能在存储函数中使用绑定变量5.如果总是忘记释放绑定变量资源，则在服务器端很容易发生资源'泄漏'。绑定变量的sql总数的限制是一个全局限制。7.9 字符集和校对字符集是指一种从二进制编码到某类字符符号的映射。校对是指一组用于某个字符集排序的规则。每一类编码字符都有其对应的字符集和校对规则。每个字符集可能有多种校对规则，并且都有一个默认的校对规则。每个校对规则都是针对某个特定的字符集的，和其他的字符集没有关系。mysql 的设置可以分为2类：创建对象时的默认值，在服务器和客户端通信时的设置。1.创建对象时的默认设置mysql服务器有默认的字符集和校对规则，每个数据库也有自己的默认值，每个表也有自己的默认值。这是一个逐层继承的默认设置。创建数据库时，将根据 character_set_server 的设置来。2.服务器和客户端通信时的设置当服务器和客户端通信时，它们可能使用不同的字符集。这是服务端将进行必要的翻译转换工作。1.服务端总是假设客户端按照 character_set_client 设置的字符来传输数据和sql语句的。2.当服务器收到客户端的 sql 语句时，它先将其转换成字符集 character_set_connection。它还使用这个设置来决定如何将数据转换成字符串3.当服务器返回数据或者错误信息给客户端时，会将其转换为 character_set_results校对规则：cs( case sensitive )ci( case insensitive )bin( 二进制存储，不区分大小 )7.11 分布式(XA)事务两阶段提交：xa 事务中有一个事务协调器来保证所有的事务参与者都完成了准备工作(第一阶段)。如果协调器收到了所有参与者都准备好的消息，就会告诉所有的事务可以提交了，这是第二阶段。实际上，在mysql中有2种xa事务。一方面，mysql 可以参与到外部的分布式事务中个；另外一方面，还可以通过xa事务来协调存储引擎和二进制日志。7.12 查询缓存mysql 查询缓存保存查询返回的完整结果。当查询命中该缓存时，mysql 会立刻返回结果，跳过了解析，优化和执行阶段。查询缓存系统会跟踪查询中涉及到的每个表，如果这些表发生变化，那么和这个表相关的所有缓存的数据都失效了。mysql 如何判断缓存命中：缓存存放在一个引用表中，通过一个哈希值引用，这个哈希值包括如下因素：即查询本身，当前要查询的数据库，客户端协议版本等。当判断缓存是否命中时，mysql不会解析，'正规化'或者参数化查询语句，而是直接使用sql语句和客户端发送过来的其他原始信息。任何字符上的不同，例如空格，注释---任何的不同，都会导致缓存的不命中。Qcache_hits/Qcache_inserts 命中率/写入 比大于 3:1 时通常查询缓存是有效的，不过这个比率最好能达到 10:1。

1.分区表

1.1 分区表的原理

1.2 分区表的类型

1.3 如何使用分区表

1.4 什么情况下会出问题

1.5 查询优化

1.6 合并表

2.视图

2.1 可更新视图

2.2 视图对性能的影响

2.3 视图的限制

3.外键约束

4.在MySQL内部存储代码

4.1 存储过程和函数

4.2 触发器

4.3 事件

4.4 在存储程序中保留注释

5.游标

6.绑定变量

6.1 绑定变量的变化

6.2 SQL 接口的绑定变量

6.3 绑定变量的限制

7.用户自定义函数

8.插件

9.字符集和校对

9.1 MySQL 如何使用字符集

创建对象时的默认设置：

MySQL 如何比较两个字符串大小：

9.2 选择字符集和校对规则

9.3 字符集和校对规则如何影响查询

10.全文索引

10.1 自然语言的全文索引

10.2 布尔全文索引

10.3 MySQL 中全文索引的变化

10.4 全文索引的限制和替代方案

10.5 全文索引的配置和优化

11.分布式(XA)事务

11.1 内部 XA 事务

11.2 外部 XA 事务

12.查询缓存

12.1 MySQL 如何判断缓存命中

12.2 查询缓存如何使用内存

12.3 什么情况下查询缓存能发挥作用

12.4 如何配置和维护查询缓存

12.5 InnoDB 查询缓存

12.6 通用查询缓存优化

12.7 查询缓存替代方案

总结

7.高性能MySQL --- MySQL 高级特性相关推荐

mysql的高级特性
1.分区表 1)分区表是一个独立的逻辑表,底层是由多个物理字表组成.实现分区的代码实际上是对一组底层表的句柄对象的封装,对分区表的请求都会通过句柄对象转化为对存储引擎的接口调用,所以分区对于SQL层来 ...
高性能mysql学习笔记--高级特性
高性能mysql 七:高级特性 1,分区表分区表是一个独立的逻辑表,但是底层由多个无力字表组成,实现分区的代码实际上是对一组地层表的句柄对象的封装,对分区表的请求,都会通过句柄对象转化成对储存引擎的 ...
尚硅谷《MySQL高级特性篇》教程发布
MySQL底层如何组织设计数据怎么理解"索引即数据,数据即索引" 海量数据和高并发场景下如何设计主键索引下推.覆盖索引对优化有什么优势如何保证主从一致性 MVCC如何解决可重 ...
【一起学习Mysql】Msql的高级特性
每日一句:虽然你没有我前女友漂亮但我一见到你就有种想跟你定下来的感觉 Mysql中除了常用的开发过程中使用到的DML.DCL等常用功能之外,还有一些高级特性,也可以帮助实现高性能的查询以及在某些场景 ...
MySQL高级特性之分布式（XA）事务的介绍
文章目录分布式(XA) 事务 1.内部XA事务 2.外部XA事务这一部分是高性能MySQL(第3版)中第七章第11节内容:关于MySQL高级特性之分布式(XA)事务的介绍,(不感兴趣的可以忽略) ...
mysql 事务sqlserver_MYSQL高级特性 -- 事务处理_sqlserver
下面以两个银行账户之间的转账为例子进行演示. 要使用mysql中的事务处理,首先需要创建使用事务表类型(如BDB = Berkeley DB或InnoDB)的表. CREATE TABLE accou ...
MySQL高级特性读书笔记
MySQL高级特性 1. 分区表对于用户来说,分区表是一个独立的逻辑表,但是底层由多个物理子表组成.实现分区的代码实际上是对一组底层表的句柄对象的封装以下场景分区表可以起到非常大的作用: 1. 表 ...
MySQL数据库 --- 高级篇
一.存储引擎 1.1.MySQL体系结构 1.1.1.连接层最上层是一些客户端和链接服务,包含本地sock 通信和大多数基于客户端/服务端工具实现的类似于TCP/IP的通信.主要完成一些类似于连接处 ...
mysql navicat 函数_Navicat for MySQL 函数高级属性讲解
原标题:Navicat for MySQL 函数高级属性讲解过程和函数是一组可以保存在服务器上的 SQL 语句.MySQL()函数高级属性主要涉及安全性.定义者.数据访问.决定性等方面的内容. Na ...
系列 | 高性能存储-MySQL数据库之存储过程揭秘
墨墨导读:本文介绍什么是存储过程?为什么要使用存储过程?如何使用存储过程?如何去使用存储过程以及怎么执行存储过程. DBASK小程序已经开设"MySQL 数据库专栏",欢迎大家关注 ...

7.高性能MySQL --- MySQL 高级特性

7.高性能MySQL --- MySQL 高级特性相关推荐

最新文章

热门文章