1、用记事本打开脚本文件，把文件依次剪切成10-15M左右的文本文件，然后再一个个执行；
2、或者在脚本导出时，分表导出，这样导出的文本size也不会很大；
以上问题虽然简便，但是步骤繁多，要是表和数据太多，着实是一种劳力折磨！另外如果表之间是有主外键关系的，分数据得小心谨慎，否则报错让你抓狂！
B. sql执行时间一般不超过多久
你好，一般是10-20毫秒。
扩展：
常见查询慢的原因常见的话会有如下几种：
1、没有索引或没有用到索引。
PS：索引用来快速地寻找那些具有特定值的记录，所有MySQL索引都以B-树的形式保存。如果没有索引，执行查询时MySQL必须从第一个记录开始扫描整个表
的所有记录，直至找到符合要求的记录。表里面的记录数量越多，这个操作的代价就越高。如果作为搜索条件的列上已经创建了索引，MySQL无需扫描任何记录
即可迅速得到目标记录所在的位置。如果表有1000个记录，通过索引查找记录至少要比顺序扫描记录快100倍。
索引类型：
普通索引：这是最基本的索引类型，没唯一性之类的限制。
唯一性索引：和普通索引基本相同，但所有的索引列只能出现一次，保持唯一性。
主键：主键是一种唯一索引，但必须指定为"PRIMARY KEY"。
全文索引：MYSQL从3.23.23开始支持全文索引和全文检索。在MYSQL中，全文索引的索引类型为FULLTEXT。全文索引可以在VARCHAR或者TEXT类型的列上创建。
2、IO吞吐量小形成了瓶颈。
PS：这是从系统层来分析MYSQL是比较耗IO的。一般数据库监控也是比较关注IO。
监控命令：$iostat -d -k 1 10
参数 -d 表示，显示设备（磁盘）使用状态；-k某些使用block为单位的列强制使用Kilobytes为单位；1 10表示，数据显示每隔1秒刷新一次，共显示10次。
C. 如何能缩短sql语句的执行时间
1. SQL优化的原则是：将一次操作需要读取的BLOCK数减到最低,即在最短的时间达到最大的数据吞吐量。
调整不良SQL通常可以从以下几点切入：
? 检查不良的SQL，考虑其写法是否还有可优化内容
? 检查子查询 考虑SQL子查询是否可以用简单连接的方式进行重新书写
? 检查优化索引的使用
? 考虑数据库的优化器
2. 避免出现SELECT * FROM table 语句，要明确查出的字段。
3. 在一个SQL语句中，如果一个where条件过滤的数据库记录越多，定位越准确，则该where条件越应该前移。
4. 查询时尽可能使用索引覆盖。即对SELECT的字段建立复合索引，这样查询时只进行索引扫描，不读取数据块。
5. 在判断有无符合条件的记录时建议不要用SELECT COUNT （*）和select top 1 语句。
6. 使用内层限定原则，在拼写SQL语句时，将查询条件分解、分类，并尽量在SQL语句的最里层进行限定，以减少数据的处理量。
7. 应绝对避免在order by子句中使用表达式。
8. 如果需要从关联表读数据，关联的表一般不要超过7个。
9. 小心使用 IN 和 OR，需要注意In集合中的数据量。建议集合中的数据不超过200个。
10. <> 用 < 、 > 代替，>用>=代替，<用<=代替，这样可以有效的利用索引。
11. 在查询时尽量减少对多余数据的读取包括多余的列与多余的行。
12. 对于复合索引要注意，例如在建立复合索引时列的顺序是F1，F2，F3，则在where或order by子句中这些字段出现的顺序要与建立索引时的字段顺序一致，且必须包含第一列。只能是F1或F1，F2或F1，F2，F3。否则不会用到该索引。
13. 多表关联查询时，写法必须遵循以下原则，这样做有利于建立索引，提高查询效率。格式如下select sum（table1.je） from table1 table1, table2 table2, table3 table3 where (table1的等值条件（=）) and (table1的非等值条件) and (table2与table1的关联条件) and (table2的等值条件) and (table2的非等值条件) and (table3与table2的关联条件) and (table3的等值条件) and (table3的非等值条件)。
注:关于多表查询时from 后面表的出现顺序对效率的影响还有待研究。
14. 子查询问题。对于能用连接方式或者视图方式实现的功能，不要用子查询。例如：select name from customer where customer_id in ( select customer_id from order where money>1000)。应该用如下语句代替：select name from customer inner join order on customer.customer_id=order.customer_id where order.money>100。
15. 在WHERE 子句中，避免对列的四则运算，特别是where 条件的左边，严禁使用运算与函数对列进行处理。比如有些地方 substring 可以用like代替。
16. 如果在语句中有not in（in）操作，应考虑用not exists（exists）来重写,最好的办法是使用外连接实现。
17. 对一个业务过程的处理，应该使事物的开始与结束之间的时间间隔越短越好，原则上做到数据库的读操作在前面完成，数据库写操作在后面完成，避免交叉。
18. 请小心不要对过多的列使用列函数和order by,group by等，谨慎使用disti软件开发t。
19. 用union all 代替 union，数据库执行union操作，首先先分别执行union两端的查询，将其放在临时表中，然后在对其进行排序，过滤重复的记录。
当已知的业务逻辑决定query A和query B中不会有重复记录时，应该用union all代替union，以提高查询效率。
数据更新的效率
1. 在一个事物中，对同一个表的多个insert语句应该集中在一起执行。
2. 在一个业务过程中，尽量的使insert,update,delete语句在业务结束前执行，以减少死锁的可能性。
数据库物理规划的效率
为了避免I/O的冲突，我们在设计数据库物理规划时应该遵循几条基本的原则(以ORACLE举例)：
?? table和index分离：table和index应该分别放在不同的tablespace中。
?? Rollback Segment的分离：Rollback Segment应该放在独立的Tablespace中。
?? System Tablespace的分离：System Tablespace中不允许放置任何用户的object。（mssql中primary filegroup中不允许放置任何用户的object）
?? Temp Tablesace的分离：建立单独的Temp Tablespace，并为每个user指定default Temp Tablespace
??避免碎片：但segment中出现大量的碎片时，会导致读数据时需要访问的block数量的增加。对经常发生DML操作的segemeng来说，碎片是不能完全避免的。所以，我们应该将经常做DML操作的表和很少发生变化的表分离在不同的Tablespace中。
当我们遵循了以上原则后，仍然发现有I/O冲突存在，我们可以用数据分离的方法来解决。
?? 连接Table的分离：在实际应用中经常做连接查询的Table，可以将其分离在不同的Taclespace中，以减少I/O冲突。
?? 使用分区：对数据量很大的Table和Index使用分区，放在不同的Tablespace中。
在实际的物理存储中，建议使用RAID。日志文件应放在单独的磁盘中。
D. using index; using where
建表
线上表50w行
线上表当前索引:
主键索引、pc_id+process_sku_id组合索引、process_sku_id单独索引
慢sql语句如下，执行时间平均300ms，低于公司标准100ms，故需优化
子查询用到process_sku_id单独索引，主查询用到pc_id+process_sku_id组合索引，综上，建立process_sku_id + pc_id组合索引即可替代原先的两个索引；
SELECT * FROM `process_sku_overflow` ORDER BY `id` DESC LIMIT ?主键索引排序，效率没问题
SELECT `pc_id`, `pc_name`, `process_date`, `process_sku_id`, `process_sku_name` , `category?_name`, `category?_name`, `category?_name`, `category?_name`, `actual_overflow_rate` FROM process_sku_overflow WHERE ? = ?where 1=2，瞬间返回，不涉及数据检索，效率很高
综上，考虑两种方案：
1.process_sku_id+process_date+pc_id联合索引 +删除现有的pc_id+process_sku_id索引
2.process_sku_id+process_date+pc_id+ actual_overflow_rate覆盖索引 +删除现有的pc_id+process_sku_id索引
以及考虑是否可以删除原索引，暂时先新增，目前表数据量50w较少，索引三个倒是也不用细究去删除，稳妥起见先并存，后续如果表数据量过多(千万级别)，考虑删除process_sku_id单独索引单独索引;
采用方案二建立覆盖索引后,子查询直接索引覆盖，主查询也在索引下推的帮助下实现了索引覆盖，性能提升
下面是过程的一些学习感悟记录,由于多次修改sql条件去测试Extra，故后续sql的explain结果均以**选中部分**执行，请勿认为每次都是执行的全部sql字句；
case1:匹配上索引，但是select 的字段不被索引覆盖
Extra信息为NULL，表示该查询只需通过索引匹配即完成了整个筛选过程，但是索引并没有包含需查询的所有字段，因此还需回表查询；
case1.1 在上一个sql语句中，将process_sku_id in括号里的数据增加到3个，成为范围查询
此时出现using index condition，即ICP，原因是此时引擎层会主动做索引下推过滤后回表查询数据给到server层用户，无需因为遇到范围查询而仅仅匹配pc_id后直接回表拿数据给server层过滤process_sku_id，减少引擎层返回过多的回表数据给到server层，“下推”其实是指原本需要在server层的过滤放到了引擎层；想了解ICP详情可以参考https://blog.csdn.net/b1303110335/article/details/105831083、https://blog.csdn.net/meser88/article/details/120953207或者网络搜“mysql 索引下推”；
case 2:如果select只查询pc_id和process_sku_id，即所需的字段都在索引中
此时应该由于索引覆盖的缘故，无需回表，直接using index；然而出现了using index; using where。各方查询，这是由于虽然索引已经覆盖了所有的字段无需回表，但此处的using where跟using index同时出现表示的是虽然索引覆盖了但在使用索引过滤时存在范围查询或者like匹配，在索引层面也经历了类似where条件的匹配，若是没有in的范围查询，则Extra显示索引覆盖；
case3:此时若在where条件中加入process_date字段，则当前索引无法覆盖需回表，则此时在索引层面由于范围查询先过滤了一下，属于using index condition，再回表查询去过滤process_date条件，因此还会有using where；
E. sql语句执行效率低，有上千万条数据，耗时3分钟
not in内外表都进行全表扫描，没有用到索引，所以很慢not extsts 的子查询能用到表上的索引。 改成：
select convert(varchar(10),scanTime,20) as 'DList' from T_SCAN
where not extsts
(
select 1 from T_Scan_image ts,T_SCAN t
where ts.scanTime = t.scanTime
)
group by convert (varchar(10),scanTime,20)
F. sybase数据库中5000笔的insert耗时单笔300ms,如何sql调优
将绝大部分的SQL查询改为存储过程，这样的操作毫无疑问可以提高部分性能。
凡是使用“select * from xxx”的操作一律具体到所需字段。
使用join连接2个以上大量数据的表，且基础数据表变化不大的查询一律使用视图，并为此视图建立索引。理由来自SQL Server联机帮助手册：
“对于标准视图而言，为每个引用视图的查询动态生成结果集的开销很大，特别是对于那些涉及对大量行进行复杂处理（如聚合大量数据或联接许多行）的视图。如果在查询中频繁地引用这类视图，可通过对视图创建唯一聚集索引来提高性能。对视图创建唯一聚集索引后，结果集将存储在数据库中，就像带有聚集索引的表一样。
G. 如何解决SQL查询速度太慢
1. 执行计划中明明有使用到索引，为什么执行还是这么慢？
2. 执行计划中显示扫描行数为 644，为什么 slow log 中显示 100 多万行？
a. 我们先看执行计划，选择的索引 “INDX_BIOM_ELOCK_TASK3(TASK_ID)”。结合 sql 来看，因为有 "ORDER BY TASK_ID DESC" 子句，排序通常很慢，如果使用了文件排序性能会更差，优化器选择这个索引避免了排序。
那为什么不选 possible_keys:INDX_BIOM_ELOCK_TASK 呢？原因也很简单，TASK_DATE 字段区分度太低了，走这个索引需要扫描的行数很大，而且还要进行额外的排序，优化器综合判断代价更大，所以就不选这个索引了。不过如果我们强制选择这个索引（用 force index 语法），会看到 SQL 执行速度更快少于 10s，那是因为优化器基于代价的原则并不等价于执行速度的快慢；
b. 再看执行计划中的 type:index，"index" 代表 “全索引扫描”，其实和全表扫描差不多，只是扫描的时候是按照索引次序进行而不是行，主要优点就是避免了排序，但是开销仍然非常大。
Extra:Using where 也意味着扫描完索引后还需要回表进行筛选。一般来说，得保证 type 至少达到 range 级别，最好能达到 ref。
在第 2 点中提到的“慢日志记录Rows_examined: 1161559，看起来是全表扫描”，这里更正为“全索引扫描”，扫描行数确实等于表的行数；
c. 关于执行计划中：“rows：644”，其实这个只是估算值，并不准确，我们分析慢 SQL 时判断准确的扫描行数应该以 slow log 中的 Rows_examined 为准。
4. 优化建议：添加组合索引 IDX_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID)
优化过程：
TASK_DATE 字段存在索引，但是选择度很低，优化器不会走这个索引，建议后续可以删除这个索引：
select count(*),count(distinct TASK_DATE) from T_BIOMA_ELOCK_TASK;+------------+---------------------------+| count(*) | count(distinct TASK_DATE) |+------------+---------------------------+| 1161559 | 223 |+------------+---------------------------+
在这个 sql 中 REL_DEVID 字段从命名上看选择度较高，通过下面 sql 来检验确实如此：
select count(*),count(distinct REL_DEVID) from T_BIOMA_ELOCK_TASK;+----------+---------------------------+| count(*) | count(distinct REL_DEVID) |+----------+---------------------------+| 1161559 | 62235 |+----------+---------------------------+
由于有排序，所以得把 task_id 也加入到新建的索引中，REL_DEVID,task_id 组合选择度 100%：
select count(*),count(distinct REL_DEVID,task_id) from T_BIOMA_ELOCK_TASK;+----------+-----------------------------------+| count(*) | count(distinct REL_DEVID,task_id) |+----------+-----------------------------------+| 1161559 | 1161559 |+----------+-----------------------------------+
在测试环境添加 REL_DEVID，TASK_ID 组合索引，测试 sql 性能：alter table T_BIOMA_ELOCK_TASK add index idx_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID);
添加索引后执行计划：
这里还要注意一点“隐式转换”：REL_DEVID 字段数据类型为 varchar，需要在 sql 中加引号：AND T.REL_DEVID = 000000025xxx >> AND T.REL_DEVID = '000000025xxx'
执行时间从 10s+ 降到 毫秒级别：
1 row in set (0.00 sec)
结论
一个典型的 order by 查询的优化，添加更合适的索引可以避免性能问题：执行计划使用索引并不意味着就能执行快。
H. 如何提高sql语句的执行效率
1、使用ordered提示
Oracle必须花费大量的时间来剖析多表的合并，用以确定表合并的最佳顺序。SQL表达式涉及七个乃至更多的表合并，那么有时就会需要超过30分钟的时间来剖析，Ordered这个提示(hint)和其他的提示一起使用能够产生合适的合并顺序。
2、使用ordered_predicates
ordered_predicates提示在查询的WHERE子句里指定的，并被用来指定布尔判断(Booleanpredicate)被评估的顺序。在没有ordered_predicates的情况下，Oracle会使用下面这些步骤来评估SQL判断的顺序：子查询的评估先于外层WHERE子句里的Boolean条件。
所有没有内置函数或者子查询的布尔条件都按照其在WHERE子句里相反的顺序进行评估，即最后一条判断最先被评估。每个判断都带有内置函数的布尔判断都依据其预计的评估值按递增排列。
3、限制表格合并评估的数量
提高SQL剖析性能的最后一种方法是强制取代Oracle的一个参数，这个参数控制着在评估一个查询的时候，基于消耗的优化器所评估的可能合并数量。
(8)sql执行超过300ms扩展阅读：
1、表设计的优化，数据行的长度不要超过8020字节，如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片，降低查询效率。
2、语句的查询优化，保证在实现功能的基础上，尽量减少对数据库的访问次数；
3、建立高效的索引创建索引一般有以下两个目的：维护被索引列的唯一性和提供快速访问表中数据的策略。
大型数据库有两种索引即簇索引和非簇索引，一个没有簇索引的表是按堆结构存储数据，所有的数据均添加在表的尾部，而建立了簇索引的表，其数据在物理上会按照簇索引键的顺序存储。个表只允许有一个簇索引。
4、强制查询转换，有时候oracle 的优化器未必能走正确的查询路线，这个时候就需要添加一些hint 之类的来规定他的执行路线。当然了，这个未必是最好的处理方案。因为虽然现在走这个路线是对的，以为因为数据的变化到这这个HINT 变得不可取。
I. 如何执行超过一百兆的sql脚本
使用osql执行一个大脚本文件
将该工具指向一个脚本文件,步骤：
a.创建一个包含一批 Transact-SQL 语句的脚本文件（如 myfile.sql）。
b.打开命令提示符，键入与下面类似的一个命令，然后按 ENTER 键：
osql -E -i input_file
其中input_file 是脚本文件及其完整路径。例如，如果脚本文件 myfile.sql 在 C:\users文件夹中，
请将参数 myfile 替换为 C:\users\myfile.sql。
该脚本文件的运行结果将出现在控制台窗口中。
如果您想将运行结果定向到一个文件，请向上述命令中添加 -o output_file 参数。例如：
osql -E -i input_file -o output_file
其中output_file 是输出文件及其完整路径。
J. 100ms的SQL把服务器搞崩溃了
一个项目上线了两个月，除了一些反馈的优化和小Bug之外，项目一切顺利；前期是属于推广阶段，可能使用人员没那么多，当然对于项目部署肯定提前想到并发量了，所以早就把集群安排上，而且还在测试环境搞了一下压测，绝对是没得问题的；但是，就在两个月后的一天，系统突然跑的比乌龟还慢，投诉开始就陆续反馈过来了。
经过排查，原来是频繁执行一条耗时100ms的SQL导致，100ms感觉不长，但就是把系统搞崩了，具体细节如下。
项目采用ABP进行开发，集成统一的认证中心(IDS4)，部分数据对接第三方系统，拆分后的这个项目架构相对简单。
考虑并发量不高，就算是高峰期也不会超过1000，于是就搞了个单台的数据库服务器(MySQL)，测试环境中经过压测，完全能抗住。
上线时，由于线上资源的关系，DB服务器的配置没有按测试环境的标准来分配，相关人员想着后续看情况进行补配。上线推的比较紧，简单评估了配置风险，初步判断没啥大问题，于是就推上线了。
相关技术栈：ABP、IdentityServer4、Autofac、AutoMapper、Quartz.NET、EF Core、Redis、MySQL等，这都不重要，重要的是100ms的SQL把系统搞崩了。
由于系统相对不大，并没有把分布式日志、调度监控，性能监控集成上去。
上线期间，前期处于使用推广阶段，一切正常。两个月后的一天，系统处于使用高峰时段，突然陆续收到反馈：系统有点卡！！！于是赶紧进行排查。
由于系统已经是集群部署的，慢这个问题首先怀疑是数据库服务器，于是让DBA的同事排查了一下，没有锁，只是有大量事务等待提交(waiting for handler commit)，通过如下命令可查的：
看到都是插入审计日志记录导致，一看日志记录频率，差不多一秒500条记录。DBA同事说可能是记录插入频繁导致，此时CPU已经爆到100%了，为了快速解决问题，于是就赶紧关掉了一些不必要的日志记录。
这么一改，稍微降了一点，没有事务提交的记录，系统勉强可以撑着用，但是CPU还是在85%~97%波动；
看到这种情况，当然还是不放心，继续排查。 中间有对服务器的配置产生过怀疑，但非常肯定的是这不是主要原因，于是和DBA的同事继续排查。
系统虽然可以正常使用，但时不时的也看看监控屏，CPU一直处于高水位状态，还是有点慌的，因为一有问题，信息和电话都要爆。
突然DBA同事发现有一个单表查询的SQL执行比较频繁，于是单独拿出来试了一下，查询时间150ms左右，这个表的数据量不大，8万左右，但没有加任何索引，因为想着数据量不大，查询时长还可接受，所以当时就没有加相关索引。
定位到这条SQL后，想到的第一步就是增加索引，在测试环境上试了一把，执行效率直接飞速提高到1ms；效果如下：
所以和DBA同事达成一致意见，在生成环境上增加复合索引( 创建索引一定要注意字段顺序 )，在中午时候，系统使用频率不太高，于是就在生成上快速加了索引，我去，CPU一下降到了20%以内，意不意外；就算在使用高峰期，也没超过20%，通过zabbix工具监控看到CPU的效果：
问题算是解决了，总算松了一口气。
这里有个问题： CPU都爆了为什么没有报警提醒，这块DBA同事正在排查相关配置。这里发现CPU爆了，还是无意的远程到服务器，发现很卡，一看CPU才知道爆了。
系统虽小，问题不大，但其实暴露的问题还是挺多。
这次线上小事故暂时分享到这，因为项目不大，所以没有做那么多监控，但以下建议，小伙伴可以参考一下：
文章来自https://www.cnblogs.com/zoe-zyq/p/16207287.html