mysql的sql文件导入有没有文件大小限制

非root用户运行MySQL，当MySQL配置比较高时，MySQL运行中生效的参数值与配置的值不一样,所以具体分析一下MySQL是怎么调整这些参数值的。 

这篇文章的目的是为了说明在系统资源不够的情况下，MySQL 是怎么调整者三个参数的。说明此文涉及到三个参数open_files_limit、 max_connections、 table_open_cache。与这三个参数相关的系统资源是打开文件数限制，即文件描述符（fd）限制。系统参数与文件描述符的关系 - max_connection & fd : 每一个MySQL connection      都需要一个文件描述符；

- table_open_cache & fd 打开一张表至少需要一个      文件描述符，如打开MyISAM需要两个fd ；

- 系统最大打开文件数可以通过 ulimit -n查看。MySQL调整参数的方式

根据配置（三个参数的配置值或默认值）计算 request_open_files（需要的文件描述符）；

  2.获取有效的系统的限制值effective_open_files；  3.根据effective_open_files调整request_open_files；  4.根据调整后的request_open_files,计算实际生效的参数值（show variables 可查看参数值）。计算request_open_filesrequest_open_files有三个计算公式：1.      // 最大连接数+同时打开的表的最大数量+其他（各种日志等等）2.     limit_1= max_connections+table_cache_size * 2 + 103.   4.      //假设平均每个连接打开的表的数量（2-4）5.      //源码中是这么写的：6.      //We are trying to allocate no less than 7.      // max_connections*5 file handles8.      limit_2= max_connections * 59.   10.    //mysql 默认的默认是500011.    limit_3= open_files_limit ? open_files_limit : 500012.  13.     所以open_files_limit期待的最低14.     request_open_files= max(limit_1,limit_2,limit_3)计算effective_open_files:MySQL 的思路： 

在有限值的的范围内MySQL 尽量将effective_open_files的值设大。 修正request_open_files

requested_open_files= min(effective_open_files, request_open_files)

重新计算参数值

修正open_files_limit

open_files_limit = effective_open_files

修正max_connections

max_connections 根据 request_open_files 来做修正。1.  limit = requested_open_files - 10 - TABLE_OPEN_CACHE_MIN * 2

如果配置的max_connections值大于limit，则将max_connections 的值修正为limit

其他情况下 max_connections 保留配置值

修正table_cache_size

table_cache_size 会根据 request_open_files 来做修正1.   // mysql table_cache_size 最小值，4002.   limit1 = TABLE_OPEN_CACHE_MIN3.   // 根据 requested_open_files 计算4.   limit2 = (requested_open_files - 10 - max_connections) / 25.   limit = max(limit1,limt2)

如果配置的table_cache_size 值大于limit，则将 table_cache_size 的值修正为limit

其他情况下table_cache_size 保留配置值

举例

以下用例在非 root 用户下运行

参数设置：

   //mysql

max_connections = 500

         table_open_cache = 999

//ulimit -n

1500

生效的值：

   open_files_limit = 1500   max_connections = min[(1500 - 10 - 800),500] = 500

table_open_cache = ( 1500 - 10 - 500) / 2 =495

简单的修改方法：

php.ini中修改upload_max_filesize=256M（这个数值可以自定义,比如说256）

反复试验多次,改了这个居然没起作用,

修改方法：

Maximum size of POST data that PHP will accept.

post_max_size = 128M

Maximum allowed size for uploaded files.

upload_max_filesize = 128M

Maximum number of files that can be uploaded via a single request

max_file_uploads = 128

重启IIS和MYSQL也无效

改了半天没用,发现在c:\windows里还有一个php.ini

覆盖后,重启IIS,就可以了.

如果从库上表 t 数据与主库不一致，导致复制错误，整个库的数据量很大，重做从库很慢，如何单独恢复这张表的数据？通常认为是不能修复单表数据的，因为涉及到各表状态不一致的问题。下面就列举备份单表恢复到从库会面临的问题以及解决办法：

场景 1

如果复制报错后，没有使用跳过错误、复制过滤等方法修复主从复制。主库数据一直在更新，从库数据停滞在报错状态（假设 GTID 为 aaaa:1-100）。

修复步骤：

在主库上备份表 t （假设备份快照 GTID 为 aaaa:1-10000）；

恢复到从库；

启动复制。

这里的问题是复制起始位点是 aaaa:101，从库上表 t 的数据状态是领先其他表的。aaaa:101-10000 这些事务中只要有修改表 t 数据的事务，就会导致复制报错 ，比如主键冲突、记录不存在（而 aaaa:101 这个之前复制报错的事务必定是修改表 t 的事务）

解决办法：启动复制时跳过 aaaa:101-10000 这些事务中修改表 t 的事务。

正确的修复步骤：

1. 在主库上备份表 t （假设备份快照 GTID 为 aaaa:1-10000），恢复到从库；

2. 设置复制过滤，过滤表 t：

CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('db_name.t')

3. 启动复制，回放到 aaaa:10000 时停止复制（此时从库上所有表的数据都在同一状态，是一致的）

START SLAVE UNTIL SQL_AFTER_GTIDS = 'aaaa:10000'

4. 删除复制过滤，正常启动复制。

注意事项：这里要用 mysqldump --single-transaction --master-data=2，记录备份快照对应的 GTID

场景 2

如果复制报错后，使用跳过错误、复制过滤等办法修复了主从复制。主、从库数据一直在更新。

修复步骤：

在主库上备份表 t （假设备份快照 GTID为 aaaa:1-10000）；

停止从库复制，GTID为 aaaa:1-20000；

恢复表 t 到从库；

启动复制。

这里的问题是复制起始位点是 aaaa:20001，aaaa:10000-20000 这些事务将不会在从库上回放，如果这里面有修改表 t 数据的事务，从库上将丢失这部分数据。

解决办法：从备份开始到启动复制，锁定表 t，保证 aaaa:10000-20000 中没有修改表 t 的事务。

正确修复步骤：

对表 t 加读锁；

在主库上备份表 t；

停止从库复制，恢复表 t；

启动复制；

解锁表 t。

如果是大表，这里可以用可传输表空间方式备份、恢复表，减少锁表时间。

---