1. sql 如何用临时表优化性能
InnoDB 类型的临时表存在的潜在问题
尽管使用 InnoDB 是性能最佳的，但可能会出现新的潜在问题。在某些特定情况下，您可能会出现磁盘耗尽和服务器中断。
与数据库中的任何其他 InnoDB 表一样，临时表具有自己的表空间文件。新文件与通用表空间一起位于数据目录中，名称为 ibtmp1。它存储所有 tmp 表。不运行手动运行 OPTIMIZE TABLE，表空间文件就会不断增长。如果你不能使用 OPTIMIZE，那么唯一能将 ibtmp1 大小缩小为零的方法，就是重新启动服务器。幸运的是，即使文件无法减小，在执行查询后，临时表也会自动删除，表空间可回收使用。现在，我们想一想以下情境：
存在未优化的查询，需要在磁盘上创建非常大的的临时表
存在优化的查询，但他们正在磁盘上创建非常大的临时表，因为你正在对此数据集进行计算（统计，分析）
高并发连接时，运行相同的查询，伴随临时表的创建
没有很多可用空间
- 在这些情况下，文件 ibtmp1 大大增加，很容易耗尽可用空间。这种情况每天发生几次，并且必须重启服务器才能完全缩小 ibtmp1 表空间。使用不可收缩的文件可以轻松耗尽磁盘空间！
- 虽然可以暂时解决问题，但这不是最佳解决方案。实际上，您可以通过逐步增加磁盘大小，来猜测具体需要的空间。如果环境位于云中，或者在非常大的虚拟平台，这很容易实现。但是使用这种解决方案，您可能会面临不必要的开支。您还可以通过设置以下配置变量将 ibtmp1 文件移动到专用大型磁盘上： [mysqld] innodb_temp_data_file_path = ../../tmp/ibtmp1:12M:autoextend
- 例如： [mysqld] innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:10G
- 退回 MyISAM 将临时表存储在磁盘上
- internal_tmp_disk_storage_engine = MYISAM
- 由于变量是动态的，您也可以在运行时设置它： SET GLOBAL internal_tmp_disk_storage_engine = MYISAM;
- 回到 MyISAM，您将大大降低写满磁盘空间的可能性。实际上，临时表将创建到不同的文件中，并在查询结束时立即删除。
- 在将存储引擎退回到 MyISAM 以减轻中断发生后，必须花时间分析查询。目标是减小磁盘上临时表的大小。本文的目的不是解释如何调查查询，而是可以依赖慢速日志，像 pt-query-digest 和 EXPLAIN 这样的工具。一些技巧：
在表上创建缺少的索引
如果不需要，可以在查询中添加更多过滤条件以更少收集的数据
重写查询以优化执行计划
可以在应用程序中使用队列管理器来序列化它们的执行或减少并发性
那么，如何避免磁盘耗尽和中断呢？
简单的解决方案：使用更大的磁盘
需要重启 MySQL 。注意，必须将路径指定为相对于数据目录。
设置 ibtmp1 大小的上限
在这种情况下，文件不能超过 10GB。可以降低宕机概率，但也是一个危险的解决方案。当数据文件达到最大值时，会查询失败并显示一个错误，提示表已满。
这个解决方案似乎违反直觉，但它可能是快速避免中断的最佳方法，并保证使用所有需要的临时表。
虽然总是有可能看到相同的问题，以防你可以在同一时间运行查询或非常接近。在我的实际案例中，这是避免所有中断的解决方案。
优化你的查询
但希望在所有优化之后，您可以返回将临时存储引擎设置为 InnoDB 以获得更好的性能。
结论
有时这些改进会产生意想不到的副作用。用于磁盘上临时表的 InnoDB 存储引擎是一个很好的改进，但在某些特定情况下，例如，如果您有未优化查询和很少的可用空间，则可能因“磁盘已满”错误而中断。将 tmp 存储引擎退回到 MyISAM 是避免中断的最快方法，但是为了返回到 InnoDB，查询的优化是更重要的事情。更大或专用的磁盘也可能有所帮助。但这是一个微不足道的建议。
2. 如何提高上百万级记录MySQL数据库查询速度
先安装 Apache Spark，查询数据库的速度可以提升10倍。
在已有的 MySQL 服务器之上使用 Apache Spark （无需将数据导出到 Spark 或者 Hadoop 平台上），这样至少可以提升 10 倍的查询性能。使用多个 MySQL 服务器（复制或者 Percona XtraDB Cluster）可以让我们在某些查询上得到额外的性能提升。你也可以使用 Spark 的缓存功能来缓存整个 MySQL 查询结果表。
思路很简单：Spark 可以通过 JDBC 读取 MySQL 上的数据，也可以执行 SQL 查询，因此我们可以直接连接到 MySQL 并执行查询。那么为什么速度会快呢？对一些需要运行很长时间的查询（如报表或者BI），由于 Spark 是一个大规模并行系统，因此查询会非常的快。MySQL 只能为每一个查询分配一个 CPU 核来处理，而 Spark 可以使用所有集群节点的所有核。在下面的例子中，我们会在 Spark 中执行 MySQL 查询，这个查询速度比直接在 MySQL 上执行速度要快 5 到 10 倍。
另外，Spark 可以增加“集群”级别的并行机制，在使用 MySQL 复制或者 Percona XtraDB Cluster 的情况下，Spark 可以把查询变成一组更小的查询（有点像使用了分区表时可以在每个分区都执行一个查询），然后在多个 Percona XtraDB Cluster 节点的多个从服务器上并行的执行这些小查询。最后它会使用map/rece 方式将每个节点返回的结果聚合在一起形成完整的结果。
3. SQL临时表使用
1、创建方法:
方法一：
create table TempTableName
或
select [字段1,字段2,...,] into TempTableName from table
方法二：
create table tempdb.MyTempTable(Tid int)
说明：
（1）、临时表其实是放在数据库tempdb里的一个用户表；
（2）、TempTableName必须带“#”，“#"可以是一个或者两个，以#(局部)或##(全局)开头的表,这种表在会话期间存在,会话结束则自动删除;
（3）、如果创建时不以#或##开头,而用tempdb.TempTable来命名它,则该表可在数据库重启前一直存在。
2、手动删除
drop table TempTableName
说明：
DROP TABLE 语句显式除去临时表，否则临时表将在退出其作用域时由系统自动除去：
（1）、当存储过程完成时，将自动除去在存储过程中创建的本地临时表。由创建表的存储过程执行的所有嵌套存储过程都可以引用此表。但调用创建此表的存储过程的进程无法引用此表；
（2）、所有其它本地临时表在当前会话结束时自动除去；
（3）、全局临时表在创建此表的会话结束且其它任务停止对其引用时自动除去。任务与表之间的关联只在单个Transact-SQL语句的生存周期内保持。换言之，当创建全局临时表的会话结束时，最后一条引用此表的Transact-SQL语句完成后，将自动除去此表。
4. sql数据查询，把多次查询结果合并插入到一个临时表里但是速度比较慢如何解决呢求教!
你合并的时候使用的是union还是union all,如果是union的话那么效率是相当低的，你还是采用union all，最后这张临时的结果有可能有重复的，你在把里面重复结果删除到你满意
5. sql server 存储过程 临时表 越来越慢
1、尽量优化语句，尽量少用游标。
2、修改较为常用的表要注意，最好先在临时表中作好运算和其它处理，最后在修改这些表，以免较慢的存储过程长时间锁定表记录，影响数据正常使用。
3、将连接超时和命令超时适当扩大，以免超时错误。
6. SQL 临时表创建索引会提高效率吗
只要你索引设置合理，当然会提升效率，其实临时表你也可以理解为存储在TempDB数据库中的物理表。
我在做复杂业务流程处理时，经常用到临时表，这样就能避免对原始大数据表的频繁检索，明显对速度有提升
7. 怎么样增快sql语句
T-SQL脚本优化技巧：
1）对于SELECT/UPDATE语句必须显示的定义所有的列,避免使用星号。
2）在执行SELECT/INSERT/UPDATE/DELETE语句时,请考虑执行规划的重用,尽量考虑用SP-EXECUTESQL存储过程。
3）优先使用 SELECT...INTO，然后使用 INSERT...SELECT，以避免大量死锁。
4）如果需要删除所有的数据,用TRUNCATE TABLE 代替DELETE 。
5）避免使用DISTINCT 语句。
6）如果你需要有限的记录,通过TOP N代替SET ROWCOUNT来控制排序取值。
7）避免使用SARGABLE的语句在WHERE子句,比如: OR, <>, !=, !<, >!, IS NULL, NOT, NOT IN, NOT LIKE 和LIKE,因为这些操作很难利用已知的索引。
8）避免使用NOT IN,可以采用IN,EXISTS NOT EXISTS和LEFT JOIN 加空值判断
--NOT EXISTS, 效率最高 SELECT a.hdr_key
FROM hdr_tbl a
WHERE NOT EXISTS (SELECT * FROM dtl_tbl b WHERE a.hdr_key = b.hdr_key) --LEFT JOIN SELECT a.hdr_key
FROM hdr_tbl a
LEFT JOIN dtl_tbl b ON a.hdr_key = b.hdr_key
WHERE b.hdr_key IS NULL --NOT IN ,效率最低 SELECT hdr_key
FROM hdr_tbl
WHERE hdr_key NOT IN (SELECT hdr_key FROM dtl_tbl) 9）使用EXISTS判断记录是否存在。
--不好的写法: IF (SELECT COUNT(*) FROM table_name WHERE column_name = 'xxx') --正确的写法: IF EXISTS (SELECT * FROM table_name WHERE column_name = 'xxx') 10）避免在GROUP BY中使用HAVING 语句。
11）GROUP BY的语句要尽量简单,不要进行GROUP BY语句的嵌套,避免在GROUP BY中包含多余的列
考虑在GROUP BY的列,进行ORDER BY排序,特别在多用户的环境下。
12）如果需要在一个包含JOIN的SELECT语句进行GROUP BY,请考虑用子查询代替JOIN. 如果必须使用GROUP BY, GROUP BY 的应该列在同一张表。
13）如果WHERE条件语句有多个AND条件,请确保至少有一个列有索引,如果没有可以建立多列复合INDEX。
14）对于SQL 无法执行自动优化的WHERE条件语句,可以通过HINTS显示的制定INDEX来提高查询的效率。
--可能不好的写法: SELECT * FROM tblTaskProcessesWHERE nextprocess = 1 AND processid IN (8,32,45) --正确的写法: SELECT * FROM tblTaskProcesses (INDEX = IX_ProcessID)WHERE nextprocess = 1 AND processid IN (8,32,45) 15）尽可能避免在WHERE条件语句中使用函数计算。
--不好的写法: WHERE SUBSTRING(firstname,1,1) = 'm' --正确的写法: WHERE firstname like 'm%' 16）在WHERE条件语句中,避免在函数中包列,如果无法避免,请考虑在该列建立INDEX。
--不好的写法: SELECT member_number, first_name, last_name
FROM members
WHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21 -- 正确的写法: SELECT member_number, first_name, last_name
FROM members
WHERE dateofbirth < DATEADD(yy,-21,GETDATE()) 17）在WHERE条件语句中,避免使用NOT 。
--不好的写法: WHERE NOT column_name > 5 --正确的写法: WHERE column_name <= 5 18）在WHERE条件语句中,推荐使用10位的日期函数。
--正确的写法: SELECT * FROM Northwind.dbo.Orders WHERE OrderDate > '12/31/1997'--不好的写法: SELECT * FROM Northwind.dbo.Orders WHERE OrderDate > '12/31/97' 19）避免使用UNION,而是用UNION ALL 。
20）使用 SQL-92 标准连接句法,为了提高性能，应优先使用连接，然后使用子查询或嵌套查询,表之间的连接使用INNER JOIN,LEFT JOIN 和RIGHT JOIN,不使用CROSS JOIN和多列表方式.。
21）多表关联避免超过5个,可以通过临时表(表变量),简化复杂的关联。
存储过程的开发和优化技巧：1）避免使用触发器TRIGGER,考虑用存储过程代替触发器
——与临时表一样，光标并不是不可使用。对小型数据集使用FAST_FORWARD 光标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用光标执行的速度快。如果开发时 间允许，基于光标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。2）考虑用UDF代替存储过程
——使用表值 UDF 时要小心，因为在变量（而不是常量）中传递某个参数时，如果在 WHERE 子句中使用该参数，会导致表扫描。还要避免在一个查询中多次使用相同的表值 UDF。但是，表值 UDF 确实具有某些非常方便的动态编译功能。3）对于频繁调用的存储过程,考虑用SP_RECOMPILE重新编译
4）使用输出语句代替返回整个数据集,输出语句的执行效率会更加高效
5）在存储过程的头部使用SET NOCOUNT ON, 通过@@ROWCOUNT来控制,这样可以减少网络流量和避免潜在的问题, 而在结束时设置 SET NOCOUNT OFF.
6）不使用SP_作为存储过程的名称,建议用USP_,这个会影响数据库的执行时间.
7）尽可能使用临时表而使用表变量,表变量可以减少上锁和重新编译的次数并且表变量不使用TEMPDB的空间,而是全部使用内存来处理数据.
8）先在例程中创建临时表，最后再显式删除临时表。将 DDL 与 DML 语句混合使用有助于处理额外的重新编译活动
9）尽可能不要在流程控制语句中使用临时表,比如:IF .. ELSE, WHILE
10）避免在事务中进行赋值和复杂计算,
--不好的写法: Create procere proc_1 As Begin Begin transaction -- step 1 verify the data -- step 2 perform calculations -- step 3 get default variable values (date, user info) -- update/insert records commit end --不好的写法: Create procere proc_1 As Begin -- step 1 verify the data -- step 2 make calculations -- step 3 get default variable values (date, user info) Begin transaction -- update/insert records commit end 上面的一些优化规则只是一般原则,在某些特殊情况下可能会有所差别,如果需要分析T-SQL的性能,可以通过查询分析器的CTRL+L 显示执行规划进行分析,也可以通过 SET STATISTICS PROFILE ON进行分析.
8. 如何提高SQL语句的查询效率
1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0
3.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num=10 or num=20
可以这样查询：
select id from t where num=10
union all
select id from t where num=20
5.in 和 not in 也要慎用，否则会导致全表扫描，如：
select id from t where num in(1,2,3)
对于连续的数值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
6.下面的查询也将导致全表扫描：
select id from t where name like '%abc%'
若要提高效率，可以考虑全文检索。
7.如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
select id from t where num=@num
可以改为强制查询使用索引：
select id from t with(index(索引名)) where num=@num
8.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where num/2=100
应改为:
select id from t where num=100*2
9.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where substring(name,1,3)='abc' // oracle总有的是substr函数。
select id from t where datediff(day,createdate,'2005-11-30')=0 //查过了确实没有datediff函数。
应改为:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1' //
oracle 中时间应该把char 转换成 date 如： createdate >= to_date('2005-11-30','yyyy-mm-dd')
10.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
11.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
12.不要写一些没有意义的查询，如需要生成一个空表结构：
select col1,col2 into #t from t where 1=0
这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：
create table #t(...)
13.很多时候用 exists 代替 in 是一个好的选择：
select num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num)
14.并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。
15.索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。
16.应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。
17.尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
18.尽可能的使用 varchar/nvarchar 代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
19.任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。
20.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。
21.避免频繁创建和删除临时表，以减少系统表资源的消耗。
22.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。
23.在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。
24.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。
25.尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。
26.使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。
27.与临时表一样，游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。
28.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。
29.尽量避免大事务操作，提高系统并发能力。
30.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。
9. 如何让有临时表的SQL语句执行计划效率高
这要看临时表的数据量啊，如果你临时表很大，采用何种执行计划都一样慢的，难道数据大的时候，你对临时表索引吗 这样也不现实啊 ，所以根本问题还是从业务层面限制临时表的数据量。