这里讨论的限制，适用于MySQL等功能的子查询或视图的使用。
这些限制适用于描述的特征23章，存储程序和视图
注意这里的一些限制适用于所有存储程序；即对存储过程和函数。也有一些具体到存储功能的限制而不是存储过程
对于存储功能的限制也适用于触发。也有一些限制特定的触发器
存储过程的限制也适用于DO事件调度器事件定义条款。也有一些特定事件的限制
SQL语句不允许在存储程序
存储程序不能包含任意的SQL语句。下面的语句是不允许的：
对于存储功能的限制
以下语句或操作不允许在存储功能。他们是在存储过程允许，除了存储在一个存储调用函数或触发器程序。例如，如果你使用FLUSH在一个存储过程，存储过程不能从存储函数或触发器称为。
限制触发器
触发器，以下附加限制：
触发器不被外国关键行动启动。
使用基于行的复制时，对从触发器不发起在主报表的活性。在奴隶的触发器使用基于语句的复制激活时。有关更多信息，参见第17.4.1.36，复制触发器”
这个RETURN允许在触发器不声明，不能返回一个值。退出触发立即使用LEAVE声明
触发器是不允许在表中mysql数据库他们也不允许information_schema或performance_schema表那些表实际上是视图和触发器是不允许在视图。
触发缓存不检测时的底层对象的元数据已经改变。如果一个触发器使用一个表，表中有自触发加载到缓存的改变，触发操作使用过时的元数据。
在存储程序的名称冲突
相同的标识符可以用于常规参数，局部变量，并表列。另外，相同的局部变量名可以使用嵌套的块。例如:
CREATE PROCEDURE p (i INT)
BEGIN
DECLARE i INT DEFAULT 0;
SELECT i FROM t;
BEGIN
DECLARE i INT DEFAULT 1;
SELECT i FROM t;
END;
END;
在这种情况下，该标识符是模糊的，下面的优先规则：
局部变量的优先级比常规参数或表列。
常规参数优先于表列
在一个块内的局部变量优先于在外块的局部变量。
变量优先于表列行为不规范。
复制的注意事项
使用存储过程可以导致复制问题。进一步讨论这个问题23.7节，“二进制日志存储程序”
这个--replicate-wild-do-table=db_name.tbl_name选择适用于表，视图和触发器。它不适用于存储过程和函数，或事件。过滤语句对后者的对象操作，使用一个或一个以上的-复制- DB选项
调试注意事项
没有存储程序的调试设备。
不支持的语法从SQL 2003标准：
MySQL存储程序的语法是基于SQL 2003标准。下列项目从标准目前不支持：
并发的考虑
为了防止相互之间的会议的问题，当客户发出声明，服务器使用例程快照和触发器可用于语句的执行。即，服务器计算程序清单，并触发功能，可用于在执行的语句，加载它们，然后继续执行语句。语句执行时，它不会看到其他会话执行的例程的变化。
最大并发，存储功能应尽量减少它们的副作用；特别是，更新在存储功能表可以减少表的并发操作。存储函数获得表锁在执行之前，避免因的顺序，语句执行不匹配的二进制日志不一致，当他们出现在日志。当基于二进制日志语句，函数调用语句，而不是记录的语句在函数执行。因此，存储功能，更新相同的底层表不并行执行。相反，存储过程不获取表级锁。在存储过程中执行的所有语句写入二进制日志，即使声明基于二进制日志。看到23.7节，“二进制日志存储程序”
事件调度器限制
以下限制特定的事件调度器：
事件的名称是区分大小写的方式处理。例如，你不能在与名称相同的数据库两事件anEvent和一个事件
一个事件可能不会被创建，修改，或删除的存储过程，触发器，或另一个事件。一个事件也不可能创造，改变，或降低存储过程或触发器。（错误# 16409，错误# 18896）
DDL语句的事件是被禁止的，LOCK TABLES声明是有效的
时间事件使用间隔YEAR，季度，MONTH，和year_month解决了几个月；那些使用其他任何间隔解决秒。有没有办法使计划发生在同一秒钟在一个给定的顺序执行的事件。此外由于舍入，自然多线程应用程序，而事实上，一个非零的时间长度需要创建事件和信号执行的事件可能多达1或2秒延时。然而，显示的时间INFORMATION_SCHEMA.EVENTS表的last_executed柱或mysql.event表的last_executed柱总是精确到一秒钟的实际活动执行时间。（参见错误# 16522。）
包含在一个事件的语句每次执行时发生在一个新的连接；因此，这些语句在特定服务器上的报表数如用户会话没有影响Com_select和com_insert显示的SHOW STATUS。然而，这样的数是在全球范围内更新。（错误# 16422）
事件不支持时间迟于UNIX时代的结束；这大约是今年年初的2038。这个日期是不是由事件调度器允许。（错误# 16396）
存储功能，用户定义的函数的引用，和表中的ON SCHEDULE条款CREATE EVENT和ALTER EVENT不支持报表。这些引用是不允许的。（见虫# 22830的更多信息。）
SIGNAL，RESIGNAL，和GET DIAGNOSTICS没有准备好的语句允许。例如，这个声明是无效的：
准备stmt1从信号SQLSTATE“二”；
SQLSTATE值类“04”没有特别的处理。他们在处理同其他例外。
在标准的SQL，第一个条件涉及的SQLSTATE返回值为以前的SQL语句。在MySQL，这是没有保证的，所以得到的主要错误，你不能这样做：
GET DIAGNOSTICS CONDITION 1 @errno = MYSQL_ERRNO;
相反，这样做：
GET DIAGNOSTICS @cno = NUMBER;
GET DIAGNOSTICS CONDITION @cno @errno = MYSQL_ERRNO;
服务器端游标实现的C API的使用mysql_stmt_attr_set()功能。同一个实现，用于存储程序的光标。服务器端游标使结果集是在服务器端生成的，而不是转移到客户端除了那些行客户端的请求。例如，如果一个客户端执行一个查询，但在第一排只感兴趣，其余行不转。
在MySQL服务器端游标是物化在一个内部临时表。最初，这是一个MEMORY表，但转换为MyISAM表时，其大小超过了最小值max_heap_table_size和tmp_table_size系统变量。同样的限制适用于内部临时表创建持有设置光标作为内部临时表的其他用途的结果。看到第8.4.4，“MySQL”使用内部临时表。实施的一个限制是一个大的结果集，检索其行通过游标可能是缓慢的。
游标是只读的；你不能使用游标更新行。
UPDATE WHERE CURRENT OF和删除当前的是无法实现的，因为不支持可更新游标。
游标nonholdable（没有被打开后提交）。
游标是一个敏感的
cursors are nonscrollable。
游标未命名。语句句柄作为光标ID。
你可以打开只有一个光标按事先准备好的声明。如果你需要多个游标，你必须准备好几种报表。
你不能用光标用于生成一个结果集如果语句不支持编写模式的声明。这包括诸如CHECK
TABLE，处理程序读取，和SHOW BINLOG EVENTS
一般来说，你不能修改一个表，选择来自同一个表中查询。例如，这个限制适用于以下形式的陈述：
DELETE FROM t WHERE ... (SELECT ... FROM t ...);
UPDATE t ... WHERE col = (SELECT ... FROM t ...);
{INSERT|REPLACE} INTO t (SELECT ... FROM t ...);
例外：前面的禁令不适用于如果修改表你使用派生表，导出表是物化而不是合并到外部查询。（见第8.2.2.3，“优化派生表、视图的引用，和公用表表达式”例子：。。。。。。。）
UPDATE t ... WHERE col = (SELECT * FROM (SELECT ... FROM t...) AS dt ...);
这里从派生表的结果是物化为一个临时表，所以相关的行t已被时间更新选择T发生
在一般情况下，你可能能够影响优化器实现派生表添加一个NO_MERGE优化提示。看到第8.9.2，“优化器提示”
行比较运算仅部分支持：
换句话说，为子查询返回的行n元组，这是支持：
（expr_1，…，expr_n[注释]）table_subquery
但这是不支持的：
(expr_1, ..., expr_n) op {ALL|ANY|SOME} subquery
支持行比较的原因IN但不是为了别人，进入通过重写它作为一个序列的实现=比较AND运营这种方法不能用于全部，ANY，或一些
在子查询中的FROM条款不相关子查询。他们是物化在整个（求值并产生一个结果集）在执行查询，所以他们无法评估每排外部查询。优化器的延迟物化到的结果是必要的，它可以被避免的物化。看到第8.2.2.3，“优化派生表、视图的引用，和公用表表达式”
MySQL不支持LIMIT在子查询子查询运营商一定：
MySQL的>SELECT * FROM t1->WHERE s1 IN (SELECT s2 FROM t2 ORDER BY s1 LIMIT 1);错误1235（42000）：这个版本的MySQL还不支持“限制/所有/任何/查询”
MySQL允许查询是指存储功能有修改数据的副作用如插入到表中。例如，如果f()插入行，以下查询可以修改数据：
选择在X（选择f()…）；
这种行为是对SQL标准的扩展。在MySQL数据库中，它可以产生不确定的结果，因为f()要执行不同的一个给定的查询优化器的选择取决于如何处理执行一次不同的数。
基于或混合格式复制的说法，这种非决定性的一个含义是，这样的查询可以在主人和奴隶产生不同的结果。
视图处理不优化：
还有就是你不能修改一个表，选择来自同一个表中查询的一般原则。看到第4号、“限制查询”
同样的原则也适用于如果从一个视图，选择从表中选择你，如果视图选择在查询和视图的表是使用合并算法评价。例子:
CREATE VIEW v1 AS
SELECT * FROM t2 WHERE EXISTS (SELECT 1 FROM t1 WHERE t1.a = t2.a);
UPDATE t1, v2 SET t1.a = 1 WHERE t1.b = v2.b;
如果视图是使用临时表的评价，你可以选择从表中查询和视图还修改外查询表。在这种情况下，视图将被存储在一个临时表，因此，你是不是真的从表中选择一个查询和修改“在同一时间“（这是你希望的力量MySQL通过指定使用诱人的算法的另一个原因ALGORITHM = TEMPTABLE在视图的定义。）
你可以使用DROP TABLE或ALTER TABLE放弃或改变一个表，用于在一个视图的定义。从没有预警结果滴或ALTER操作，即使这无效的观点。相反，后来发生了一个错误，使用视图时。CHECK
TABLE可用于检查已失效的观点滴或ALTER运营
关于可更新视图，视图的总体目标是，如果任何的观点在理论上是可更新的，它应该在实践中更新。MySQL尽快。许多理论上可更新的视图可以更新了，但是仍然存在局限性。详情见第23.5.3，”Updatable和可插入的意见”
存在一个与当前的视图实现的缺点。如果一个用户被授予必要的权限来创建一个视图（基本的CREATE VIEW和SELECT特权），用户将无法调用SHOW CREATE VIEW该对象除非用户也是理所当然的SHOW VIEW特权
这一缺陷可以导致问题备份数据库mysqldump，这可能是由于权限不足而失败。这个问题是错误的# 22062描述。
解决方法的问题是管理员手动发放SHOW VIEW他被授予用户的特权CREATE VIEW因为MySQL，不授予它隐含在视图中创建。
视图没有索引，因此索引提示不适用。使用索引提示时选择的观点是不允许的。
SHOW CREATE VIEW显示视图的定义使用作为alias_name每一列的条款。如果列从表达式中创建，默认别名是文字表达，这是相当长的。列名称的别名CREATE VIEW陈述对64个字符的最大柱长度检查（不是最大的别名长度为256个字符）。因此，从输出创建视图SHOW
CREATE VIEW如果任何列别名超过64个字符的失败。这可以在下面的意见的情况下太久的别名问题：
对于任何一个问题的解决方法是修改每个问题的视图定义中使用别名，提供较短的列名称。然后，将正确的复制，并可以扔和重新加载而造成的误差。修改定义，下降，再创建视图DROP
VIEW和CREATE VIEW，或更换的定义CREATE OR REPLACE
VIEW
这发生在加载视图定义在转储文件的问题，另一个解决方法是编辑转储文件来修改它CREATE VIEW声明.然而，这并没有改变原来的视图定义，为后续转储操作引起的问题。
XA事务的支持是有限的InnoDB存储引擎
为“外部XA，“一个MySQL服务器作为一个资源管理器和客户端程序作为事务经理。为“内部XA“，存储在MySQL服务器作为RMS引擎和服务器本身作为一个TM。内部XA支持是由个人存储引擎的能力有限。内部XA是处理XA事务，涉及多个存储引擎所需。内部XA的实施需要一个存储引擎支持两阶段提交的表格处理水平，目前这是真正的唯一InnoDB
为XA
START，的加入和RESUME不支持条款
为XA
END，的暂停[转移]条款是不支持的
的要求，bqual部分的xid价值是不同的每个XA事务在全球的交易是当前MySQL XA实施限制。它不是XA规范的一部分。
XA事务是两部分的二进制日志写。什么时候XA PREPARE 发行，第一部分交易了XA准备用一个初始gtid。一XA_prepare_log_event用于识别的二进制日志等交易。什么时候xa commit或XA ROLLBACK发行、交易的第二部分仅包含xa commit或XA ROLLBACK声明是用第二gtid。请注意，本次交易的初始部分，经事件日志_ _ XA _准备，不一定遵循XA COMMIT或xa回滚，可使交织的二进制日志的任意两XA事务。对XA事务的两部分甚至可以出现在不同的二进制日志文件。这意味着XA事务PREPARED直到一个明确的国家现在是持续的xa commit或XA
ROLLBACK声明的发布，确保XA事务是兼容的复制。
在一个复制的奴隶，XA事务准备完毕后，它是从应用线程分离，并可以提交或回滚任何线程的奴隶。这意味着同样的XA事务可以出现在events_transactions_current不同的国家在不同的线程表。这个events_transactions_current表格显示最新监测交易事件的线程的当前状态，不更新状态时，线程空闲时。所以XA事务仍然可以显示在制备对原应用线程状态，在它被另一个线程处理。为了确认XA事务仍在PREPARED国家需要恢复，使用XA
RECOVER声明而不是性能架构交易表。
使用XA事务存在以下限制：
XA事务的不完全弹性的意外停止相对于二进制日志。如果有意外停机当服务器中执行XA
PREPARE，xa commit，XA
ROLLBACK，或xa commit…一个阶段声明中，服务器可能无法恢复到正确的状态，使服务器处于不一致状态的二进制日志。在这种情况下，二进制日志可能包含额外的XA事务，是不适用的，或XA小姐交易的应用。另外，如果gtids启用，恢复后@@GLOBAL.GTID_EXECUTED不正确的描述已经应用的交易。注意，如果一个意外停机之前发生XA准备，之间XA PREPARE和xa commit（或XA
ROLLBACK），或后xa commit（或XA ROLLBACK），服务器和二进制日志被正确恢复和采取一致的状态。
复制二进制日志过滤器或过滤器与XA事务的组合使用是不支持的。过滤表可能导致XA事务在一个复制的奴隶是空的，空的XA事务不支持。同时，与设置master_info_repository=TABLE和relay_log_info_repository=TABLE在一个复制的奴隶，成为MySQL 5.0违约，交易的数据引擎的内部状态发生改变后，过滤XA事务，可以成为与复制的事务上下文状态不一致。
错误ER_XA_REPLICATION_FILTERS登录时，XA事务是由复制过滤的影响，交易是否是空的结果。如果交易是不是空的，复制的奴隶可以继续运行，但你应该采取措施停止复制过滤器的使用XA事务以避免潜在的问题。如果交易是空的，复制的奴隶停止。在这种情况下，复制的奴隶可能会在一个不确定的状态，在复制过程中的一致性可能会受到损害。特别是，该gtid_executed建立在奴隶的奴隶，主人可能不一致。要解决这种情况，隔离主停止复制，然后检查gtid一致性的复制拓扑。取消生成错误消息的XA事务，然后重新启动复制。
XA事务被认为是基于语句的复制不安全。如果两XA事务提交并联在主正在对反奴隶的准备，锁定的依赖可能不能安全地解决，并有可能复制失败对奴隶的僵局。这种情况的出现有单线程或多线程复制的奴隶。什么时候binlog_format=STATEMENT是集，一个警告是DML语句在XA事务发布。什么时候binlog_format=MIXED或binlog_format=ROW是集，DML语句在XA事务记录使用基于行的复制，和潜在的问题是不存在的。
笔记
MySQL 5.7.7之前，XA事务不被复制在所有兼容。这是因为XA事务中PREPARED国家将回滚在干净的服务器关机或客户端断开。同样，XA事务中制备国家仍然存在PREPARED如果服务器被关闭，然后重新开始正常的状态，但交易的内容无法写入二进制日志。在这些情况下，XA事务不能正确复制。
标识符存储在mysqlDatabase tables（用户，db，等等）使用UTF8，但标识符可以包含在基本多文种平面只有角色（BMP）。增补字符是不允许在标识符。
这个ucs2，UTF16，utf16le，和utf32字符集有以下限制：
这个REGEXP和RLIKE运营商在字节明智的方式工作，所以他们不多字节安全可能与多字节字符集产生意外的结果。此外，这些运营商比较字符的字节值和重音字符不相等的即使给定整理对待平等。
性能模式避免了使用互斥锁来收集或产生的数据，所以有没有一致性的保证和结果有时是不正确的。事件的价值performance_schema表格是非消耗性和非消耗性的。
如果救你的另一个表中的事件的信息，不应该假定原始事件仍会以后可。例如，如果您选择事件从performance_schema表到一个临时表，想加入，表与原始表后，可能没有比赛。
mysqldump和BACKUP
DATABASE忽略表中performance_schema数据库
表中的performance_schema数据库无法锁定锁定表，除了setup_xxx表
表中的performance_schema无法将数据库索引
表中的performance_schema是不可复制的数据库
这类大学西部可能每小时的平台。《performance_timers表格显示，事件计时器是可用的。如果此表中的值对于一个给定的定时器的名字是无效的，，是不支持你的平台。
仪器适用于存储引擎可能无法实现对所有存储引擎。每一方的发动机仪表是发动机维修人员的责任。
本节的第一部分描述了描述在认证框架的适用性一般限制第6.3.10，“认证”。第二部分介绍了第三方连接器开发人员可以确定在何种程度上的连接器可以利用认证能力以及采取何种措施变得更柔顺。
术语“本地认证“用在这里指的是对存储在密码认证mysql.user表这是由旧的MySQL服务器提供相同的认证方法、认证实施之前。“Windows本地认证“是指用一个用户已经登录到Windows的资格认证，由Windows本地认证插件实现的（“窗口插件“for short）。
一般认证限制
Conectory，Conectory / C：使用这些连接器的客户只能通过账户，使用本地身份验证连接到服务器。
例外：一个连接器支持可插拔认证是否建立链接libmysqlclient动态（而非静态）和加载当前版本libmysqlclient如果是安装版，或者如果连接器编译链接从源电流libmysqlclient
有关编写连接器从默认的服务器端的身份验证插件服务器处理信息的信息，参见身份验证插件连接器的写作注意事项
连接器/网：客户使用连接器/网可以通过账户，使用本地身份验证或Windows本地身份验证连接到服务器。
连接器/ PHP使用此连接器的客户只能通过账户，使用本地身份验证连接到服务器，当编译使用MySQL自带的驱动PHP（mysqlnd）
Windows本地认证：通过一个帐户使用Windows插件连接需要Windows域设置。没有它，使用NTLM验证，只有本地连接是可能的；即，客户端和服务器必须运行在同一台计算机上。
代理用户：代理用户的支持是可以在一定程度上，客户可以通过账户认证与实施的代理用户功能插件连接（即插件，可以返回一个不同的连接用户的用户名）。例如，PAM和Windows插件支持代理用户。这个mysql_native_password和sha256_password身份验证插件默认不支持代理的用户，但可以这样做；看代理服务器支持用户映射
复制奴隶：复制既可以采用主帐号使用本地认证，但也可以通过主帐号如果要求客户端插件可以使用外来身份验证连接。如果插件是建成libmysqlclient，默认情况下它是可用的。否则，插件必须安装在从动侧的目录由奴隶命名plugin_dir系统变量
FEDERATED表一FEDERATED表只能通过远程服务器使用本地认证帐户访问远程表。
可插拔认证及第三方连接器
第三方接口开发人员可以使用下列准则确定准备一个连接器利用认证能力以及采取何种措施变得更柔顺：
现有的连接器，没有修改，使用本地认证和客户端使用的连接器只能通过账户，使用本地身份验证连接到服务器。然而，你应该测试对一个新版本的服务器验证这样的连接也没有问题的连接器。
例外：如果一个连接器可能链接到它可插拔认证没有任何变化的工作libmysqlclient动态（而非静态）和加载当前版本libmysqlclient如果这个版本是安装的。
利用认证功能，连接器，libmysqlclient为应对当前版本的链接libmysqlclient。这使得连接器支持连接虽然户口要求客户端插件现在建成的libmysqlclient（如PAM认证和Windows插件Windows本地认证需要明文插件）。结合当前libmysqlclient也使连接器访问客户端插件安装在默认的MySQL插件目录（通常是目录的本地服务器的默认值为plugin_dir系统变量
如果一个连接器连接libmysqlclient动态，必须确保新版本libmysqlclient安装在客户端的主机，它在运行时加载的连接器。
一个连接器支持一个给定的认证方法来实现直接在客户端/服务器协议的另一种方式。连接器/网采用这种方法提供Windows本地认证支持。
如果连接器应该能够从默认的插件目录目录不同负载的客户端插件，它必须实现对客户端用户指定目录的一些手段。的可能性，这包括一个命令行选项或环境变量，连接器可以获取目录名。标准的MySQL客户端程序如MySQL和mysqladmin实现了一个--plugin-dir选项参见第27.7.13，“C API客户端插件功能”
代理支持用户通过连接器取决于，如本节前面所述，是否认证方法，它支持用户许可证代理。
本节列出MySQL 8的电流限制。
MySQL的数据库的数量没有限制。底层的文件系统可能对目录的数量限制。
MySQL表的数量没有限制。底层的文件系统可以对文件表示表数量限制。个人存储引擎可能造成发动机特定的约束。InnoDB允许多达4亿表
有效最大表大小的MySQL数据库通常是由操作系统对文件大小的限制决定的，不是由MySQL内部限制。对最新信息的操作系统的文件大小限制，指的是特定于您的操作系统的文件。
Windows用户，请注意脂肪，VFAT（FAT32）是不适合生产使用MySQL。而不是使用NTFS。
如果你遇到了一个全表误差，有几个原因，可能发生：
MySQL有4096列，每桌的硬限制，但有效的最大可能对一个给定的表少。准确的列的限制取决于几个因素：
对于一个给定的表的行大小的最大值是由几个因素决定的：
一个MySQL表的内部表示的最大行大小限制为65535字节，即使存储引擎能够支持更大的行。BLOB和TEXT列只贡献9到12字节的行大小限制，因为它们的内容是从行的其余部分分开存放。
一个最大的行大小InnoDB表，它适用于在本地数据库中存储的数据页，略小于半页为4KB，8KB，16KB、32KBinnodb_page_size设置例如，最大行大小略小于8KB为默认16kbInnoDB页面大小。对于64kb页，最大行大小略小于16kb。看到第15.8.1.7”限制，InnoDB表”
如果一行可变长度列超过InnoDB行大小的最大值，InnoDB选择可变长度列外页存储到行符合InnoDB行大小限制。数据量存储在本地的变量存储页面不同的行格式长度列。有关更多信息，参见15.10节，“InnoDB行存储和列格式”
不同的存储格式，使用不同数量的页面头部和尾部的数据，从而影响可行的存储量。
行大小限制的例子
MySQL的最大行大小限制为65535字节是表现在InnoDB和MyISAM实例。的执行限制无论存储引擎，即使存储引擎能够支持较大的行。
mysql> CREATE TABLE t (a VARCHAR(10000), b VARCHAR(10000),
c VARCHAR(10000), d VARCHAR(10000), e VARCHAR(10000),
f VARCHAR(10000), g VARCHAR(6000)) ENGINE=InnoDB CHARACTER SET latin1;
ERROR 1118 (42000): Row size too large. The maximum row size for the used
table type, not counting BLOBs, is 65535. This includes storage overhead,
check the manual. You have to change some columns to TEXT or BLOBs
MySQL的>CREATE TABLE t (a VARCHAR(10000), b VARCHAR(10000),c VARCHAR(10000), d VARCHAR(10000), e VARCHAR(10000),f VARCHAR(10000), g VARCHAR(6000)) ENGINE=MyISAM CHARACTER SET latin1;错误1118（42000）：行尺寸太大。所使用的表式的行大小的最大值，不可计数的斑点，是65535。这包括存储开销，查手册。你必须改变一些列的文本或斑点
在下面的MyISAM例如，改变柱TEXT避免了65535字节的行大小限制和允许操作成功是因为BLOB和TEXT列只贡献9到12字节的行大小。
MySQL的>CREATE TABLE t (a VARCHAR(10000), b VARCHAR(10000),c VARCHAR(10000), d VARCHAR(10000), e VARCHAR(10000),f VARCHAR(10000), g TEXT(6000)) ENGINE=MyISAM CHARACTER SET latin1;查询行，0行受影响（0.02秒）
操作成功的InnoDB因为改变一个列表TEXT避免MySQL 65536字节的行大小限制，和InnoDB从可变长度列的页面存储避免InnoDB行大小限制
MySQL的>CREATE TABLE t (a VARCHAR(10000), b VARCHAR(10000),c VARCHAR(10000), d VARCHAR(10000), e VARCHAR(10000),f VARCHAR(10000), g TEXT(6000)) ENGINE=InnoDB CHARACTER SET latin1;查询行，0行受影响（0.02秒）
对于可变长度列存储包括长度字节，并计入行大小。例如，一个VARCHAR(255)
CHARACTER SET utf8mb3柱需要两个字节来存储值的长度，所以每个值可以达到767字节。
该语句创建表t1成功因为栏目需要32765 2字节和32766 2字节，属于65536字节的行大小的最大值：
MySQL的>CREATE TABLE t1(c1 VARCHAR(32765) NOT NULL, c2 VARCHAR(32766) NOT NULL)ENGINE = InnoDB CHARACTER SET latin1;查询行，0行受影响（0.02秒）
该语句创建表t2不能因为，虽然列长度是65536的最大字节长度内，另外两个字节必须记录的长度，使行的大小超过65536字节：
MySQL的>CREATE TABLE t2(c1 VARCHAR(65535) NOT NULL)ENGINE = InnoDB CHARACTER SET latin1;错误1118（42000）：行尺寸太大。所使用的表式的行大小的最大值，不可计数的斑点，是65535。这包括存储开销，查手册。你必须改变一些列的文本或斑点
降低柱长度以方便或不允许声明成功。
mysql> CREATE TABLE t2
(c1 VARCHAR(65533) NOT NULL)
ENGINE = InnoDB CHARACTER SET latin1;
Query OK, 0 rows affected (0.01 sec)
为MyISAM桌子,无效的栏目需要额外的空间在连续记录是否值NULL。每个无效的需要一点额外的列，以最接近的字节。
该语句创建表t3不能因为MyISAM需要的空间无效的除了可变长度列长度字节所需的空间列，导致行大小超过65535字节：
mysql> CREATE TABLE t3
(c1 VARCHAR(32765) NULL, c2 VARCHAR(32766) NULL)
ENGINE = MyISAM CHARACTER SET latin1;
ERROR 1118 (42000): Row size too large. The maximum row size for the used
table type, not counting BLOBs, is 65535. This includes storage overhead,
check the manual. You have to change some columns to TEXT or BLOBs
有关InnoDB无效的列存储，看第15.8.1.2，“物理行结构的InnoDB表”
InnoDB限制行大小（数据存储在本地数据库中的页）略少于一半的数据库页为4KB，8KB，16KB、32KBinnodb_page_size设置，并略小于64kb页16kb。
该语句创建表t4不能因为定义列超过16KB的行大小限制InnoDB网页
mysql> CREATE TABLE t4 (
c1 CHAR(255),c2 CHAR(255),c3 CHAR(255),
c4 CHAR(255),c5 CHAR(255),c6 CHAR(255),
c7 CHAR(255),c8 CHAR(255),c9 CHAR(255),
c10 CHAR(255),c11 CHAR(255),c12 CHAR(255),
c13 CHAR(255),c14 CHAR(255),c15 CHAR(255),
c16 CHAR(255),c17 CHAR(255),c18 CHAR(255),
c19 CHAR(255),c20 CHAR(255),c21 CHAR(255),
c22 CHAR(255),c23 CHAR(255),c24 CHAR(255),
c25 CHAR(255),c26 CHAR(255),c27 CHAR(255),
c28 CHAR(255),c29 CHAR(255),c30 CHAR(255),
c31 CHAR(255),c32 CHAR(255),c33 CHAR(255)
) ENGINE=InnoDB ROW_FORMAT=DYNAMIC DEFAULT CHARSET latin1;
ERROR 1118 (42000): Row size too large (> 8126). Changing some columns to TEXT or BLOB may help.
In current row format, BLOB prefix of 0 bytes is stored inline.
以下限制适用于Windows平台的MySQL：
进程的内存
在Windows 32位平台上，这是不可能的默认使用超过2GB的内存在一个单一的过程，包括MySQL。这是因为在Windows 32位的物理地址限制是4GB和设置在Windows默认是虚拟地址空间之间的核分裂（2GB）和用户/应用程序（2GB）。
一些版本的Windows有一个启动时间设置来启用大型应用程序通过减少内核的应用。另外，使用超过2GB，使用一个64位的Windows版本。
文件系统的别名
当使用MyISAM表，你不能使用别名在窗口链接到另一个卷上的数据文件，然后链接到主要的MySQLdatadir位置
这种设备通常用于将数据和索引文件来袭击或其他快速解决方案。
端口数量有限
Windows系统有大约4000端口可用于连接的客户端，并在端口的连接关闭后，它需要两到港前可重复使用4分钟。在这种情况下，客户端连接和断开以很高的速度从服务器，所有可用的端口，用于在封闭的港口成为可用的又是可能的。如果发生这种情况，MySQL服务器似乎反应迟钝，即使是运行。港口可以由其他应用程序运行的机器一样，在这种情况下，可用MySQL端口数较低。
有关此问题的更多信息，参见http://support.microsoft.com/default.aspx?scid=kb;en-us;196271
DATA DIRECTORY和索引目录
这个DATA DIRECTORY选项CREATE TABLE只支持WindowsInnoDB表中所描述的第15.7.5”创建文件，每个表的表空间在数据目录”。为MyISAM和其他存储引擎的数据目录和INDEX
DIRECTORY选项CREATE
TABLE忽略任何一个功能在Windows和其他平台realpath()呼叫
DROP
DATABASE
你不能删除数据库正在使用由另一个会话。
不区分大小写的名字
文件名不区分大小写的Windows，所以MySQL数据库和表的名称也不区分大小写的Windows。唯一的限制是，数据库和表的名称必须使用相同的情况下，在一个给定的语句中指定。看到第9.2.2，“标识符大小写敏感”
目录和文件名
在Windows中，MySQL服务器支持，与当前的ANSI代码页只兼容目录和文件名。例如，下面的日本目录的名字将不会在西部地区工作（代码页1252）：
datadir="C:/私たちのプロジェクトのデータ"
同样的限制适用于目录和文件名中提到的SQL语句，如数据文件的路径名LOAD DATA
INFILE
这个\路径名的字符分割
在Windows路径名称组件是分开的\性格，这也是MySQL转义字符。如果你使用的是LOAD DATA
INFILE或SELECT ... INTO
OUTFILE，使用Unix风格的文件名/人物
mysql> LOAD DATA INFILE 'C:/tmp/skr.txt' INTO TABLE skr;
mysql> SELECT * INTO OUTFILE 'C:/tmp/skr.txt' FROM skr;
另外，你必须加倍的\人物
MySQL的>LOAD DATA INFILE 'C:\\tmp\\skr.txt' INTO TABLE skr;MySQL的>SELECT * INTO OUTFILE 'C:\\tmp\\skr.txt' FROM skr;
问题与管
管道不可靠地从Windows命令行提示工作。如果管道包括角色^Z/char（24），Windows认为遇到文件结束和终止程序。
这主要是一个问题，当你试图将一个二进制日志如下：
C:\> mysqlbinlog binary_log_file | mysql --user=root
如果你有一个问题应用日志和怀疑，这是因为一个^Z/char（24）字符，你可以使用下面的方法：
C:\> mysqlbinlog binary_log_file --result-file=/tmp/bin.sql
C:\> mysql --user=root --execute "source /tmp/bin.sql"
后者的命令还可以用来可靠地在任何可能包含二进制数据的SQL文件读取。