这是一个创建于 3149 天前的主题，其中的信息可能已经有所发展或是发生改变。
之前通过修改，几百 M 的好像可以上传了，但是这 2G 的死活不成功，修改 php.ini 配置文件中：
max_execution_time （ php 页面执行最大时间）=6000
max_input_time （ php 页面接受数据最大时间）=6000
memory_limit=4096 （ 4G ）
upload_max_filesize （最大文件限制）=4096 （ 4G ）
post_max_size （ post 大小限制）=4096 （ 4G ）
修改了 phpmyadmin 的 config：
ExecTimeLimit=0 （不限制时间）
import 页面的内存限制 2*2048*1024*1024=4G
max_execution_time （ php 页面执行最大时间）=6000
max_input_time （ php 页面接受数据最大时间）=6000
memory_limit=4096 （ 4G ）
upload_max_filesize （最大文件限制）=4096 （ 4G ）
post_max_size （ post 大小限制）=4096 （ 4G ）
修改了 phpmyadmin 的 config：
ExecTimeLimit=0 （不限制时间）
import 页面的内存限制 2*2048*1024*1024=4G
41 条回复 2017-05-31 00:37:44 +08:00
 | 1 cxbig 2017 年 5 月 29 日 via iPhone  1 这是什么场景？ 1. 不要用 http 上传这么大的文件 2. 一定要上传也最好是.gz 类的压缩格式 3. 除本地测试环境，其他场合用 phpmyadmin 不安全 建议：使用基于 SSH 的通道连接远程数据库，用 MySQL Workbench 或 Navicat 之类的客户端操作。 |
 | 2 changwei 2017 年 5 月 29 日 via Android 4 别用 navicat 等工具远程导入数据库，我上次导入一个一百多 m 的数据库导入了六个小时。建议先 ftp 上传，然后直接使用 mysql 控制台的 source 命令导入这样速度是最快的而且最安全。 |
 | 3 ToughGuy 2017 年 5 月 29 日 有种格式叫做 sql.gz |
 | 4 shiny PRO SQL 的压缩比很高的，可以试试压缩下。 如果你压缩后还有 2G 就不要用 phpMyAdmin 上传了吧。 |
 | 5 iamfirst 2017 年 5 月 29 日 先压缩打包上传到服务器，再用命令行导入 |
 | 6 claysec 2017 年 5 月 29 日 console upload 进去，web 端太大的文件不好支持 |
 | 7 anubiskong 10 年了吧。。。这个月经问题 |
| 8 anubiskong 2017 年 5 月 29 日 1 我只是觉得自己老了，大家别理我 |
 | 9 qiukong 2017 年 5 月 29 日 @anubiskong 10 年了，这类问题依然存在，可见互联网并没有取得什么发展…… |
 | 10 lsido 2017 年 5 月 29 日 via Android 为啥想用 phpmyadmin 来处理 2g 的数据，一般上了百 M 的，基本用命令行是最有效的解决方式 |
 | 11 tianxiacangshen OP @shiny 压缩之后 280M，还是不行 |
| 12 tianxiacangshen OP @lsido 本地测试数据用，并非服务器 |
 | 13 zhaohehedola 2017 年 5 月 29 日 有可能是 web 服务器 对文件大小有限制 |
| 14 lsido 2017 年 5 月 29 日 via Android @tianxiacangshen 本地也用命令行 source 导入啊，而且少了上传，不是更方便吗 |
 | 15 Reign 2017 年 5 月 29 日 强悍，我超过了 100M 的 sql 都是用的命令行导入 |
 | 16 zhengkai 2017 年 5 月 29 日 mysql < foo.sql zcat foo.sql.gz | mysql |
 | 17 allenhu 2017 年 5 月 29 日 via Android 好逗，浏览器上传 2g 怎么传上去的 |
 | 18 yumijie 2017 年 5 月 29 日 感觉楼主是要测试极限的 |
| 19 shiny PRO @tianxiacangshen 不要忘了改 nginx/apache 的文件尺寸限制。另外可以描述下页面的反应。 |
| 20 tianxiacangshen OP |
| 21 tianxiacangshen OP @ToughGuy 对这种纯文本的 sql 文件来说，gz 和 zip 压缩没区别，亲测 |
| 22 tianxiacangshen OP @zhaohehedola 本地 wamp 测试环境 |
 | 23 sfree2005 2017 年 5 月 29 日 实在不行 就把 2G 的 sql 文件分了吧。数据量大的表自己一个 sql，其他的一个 sql. 还有就是看下硬盘空间什么的够不够,给个至少 4G 剩余空间吧 |
| 24 zhaohehedola 2017 年 5 月 29 日 @tianxiacangshen 本地环境也是要走 本地的 web 服务器的 |
 | 25 Famio 2017 年 5 月 29 日 这么想不开，2G 的 sql 用 web 上传吗= = |
| 26 tianxiacangshen OP @sfree2005 是，最后一条路就是将 sql 文件分成多份，问题是用 sublime 打开这么大的文件 sublime 也扛不住，有时候 1G 的 sublime 都能抗住 |
| 27 sfree2005 2017 年 5 月 29 日 @tianxiacangshen #26 那这个 2G 也是从某个数据库导出来的吧，导出来的时候只选择不同的表分几次导出试试？ |
 | 28 wwww961h 2017 年 5 月 29 日 用别的工具，别用 phpmyadmin，实测 phpmyadmin 对 500M 以上的文件都不怎么好 |
 | 29 vovov 2017 年 5 月 29 日 先用 ssh 或者 ftp 上传到服务器，然后再服务器本地导入就可以了。 |
 | 30 sorkl 2017 年 5 月 29 日 via iPhone @tianxiacangshen 不可以用 mysqlimport ？改了 PHP 配置没用吧，mysql 也有文件大小限制 |
| 31 sorkl 2017 年 5 月 29 日 via iPhone 命令行下直接卡死？你是 Linux 导出导入到 windows ？有可能是编码问题。确实存在这样的奇葩问题 |
 | 32 ddd2500 2017 年 5 月 29 日 为什么不用命令行？ 或者用 http://www.ozerov.de/bigdump/ |
 | 33 laogui 2017 年 5 月 29 日 以前用虚拟主机没命令行权限，用 bigdump 导入过上 G 的数据库文件。 |
| 34 qiukong 2017 年 5 月 30 日 via iPhone 1 给你讲 phpmyadmin 的原理是一次性执行你 sql 里的所有语句。你就算压缩成 280MB 上传，他也是先解压，然后再执行那 2GB 的文本命令。 先不说执行 2GB 命令会不会超时的问题，执行的第一步是把文件读入内存，基本占用文件自身的 10 倍左右。你先看看内存有没有 20GB 再说吧…… |
 | 35 Ranh 2017 年 5 月 30 日 我前段时间才用 source a.sql 导入过一个 10 多 G 的 sql 文件，完全没问题。 |
 | 36 kslr 2017 年 5 月 30 日 via Android MySQL 自带的命令就挺好用，导过四十多 g 工作都是正常。 |
 | 37 mingyun 2017 年 5 月 30 日 或者写代码命令行执行批量导入 |
38
GoBeyond 2017 年 5 月 30 日 via Android 这么大就别拿 pma 折腾了
你要是用的虚拟主机那类的东西，发工单让服务商给你解决
如果你要是自己用 vps，sql 传上去，cd 到 sql 文件位置，bash 下进 mysql 命令行模式，source 进你的 sql 就可以了
你要是用的虚拟主机那类的东西，发工单让服务商给你解决
如果你要是自己用 vps，sql 传上去，cd 到 sql 文件位置，bash 下进 mysql 命令行模式，source 进你的 sql 就可以了
| 39 GoBeyond 2017 年 5 月 30 日 via Android 本地 wamp 是自己带 mysql 命令行客户端的吧？ 不然从别人那里复制一个过来 |
 | 40 yuweining123 2017 年 5 月 30 日 2G 数据很多嘛！！！ |
 | 41 maskerTUI 2017 年 5 月 31 日 via Android 直接命令行导入就好了，我以前 20g 的 sql 文件导入都没问题，卡的时候等就好了 |
Select Language