临时表

1．合理使用索引 索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。索引的使用要恰到好处，其使用原则如下： ●在经常进行连接，但是没有指定为外键的列上建立索引，而不经常连接的字段则由优化器自动生成索引。 ●在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引。 ●在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。 ●如果待排序的列有多个，可以在这些列上建立复合索引（compound index）。 ●使用系统工具。如Informix数据库有一个tbcheck工具，可以在可疑的索引上进行检查。在一些数据库服务器上，索引可能失效或者因为频繁操作而使得读取效率降低，如果一个使用索引的查询不明不白地慢下来，可以试着用tbcheck工具检查索引的完整性，必要时进行修复。另外，当数据库表更新大量数据后，删除并重建索引可以提高查询速度。 2．避免或简化排序 应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素： ●索引中不包括一个或几个待排序的列；

建表注意事项： 对于建表大家都不陌生，这里主要说明一下几点注意实现： 1、大数据字段最好剥离出单独的表，以便影响性能 2、使用varchar，代替char，这是因为varchar会动态分配长度，char指定为20，即时你存储字符“1”，它依然是20的长度 3、给表建立主键，看到好多表没主键，这在查询和索引定义上将有一定的影响 4、避免表字段运行为null，如果不知道添加什么值，建议设置默认值，特别int类型，比如默认值为0，在索引查询上，效率立显。 5、建立索引，聚集索引则意味着数据的物理存储顺序，最好在唯一的，非空的字段上建立，其它索引也不是越多越好，索引在查询上优势显著，在频繁更新数据的字段上建立聚集索引，后果很严重，插入更新相当忙。 6、组合索引和单索引的建立，要考虑查询实际和具体模式. SQL语句注意事项： 熟悉SQL的人，都会写SQL语句，但到底效率如何，十万以下的数据量，根本没任何区别，但一些基础性的东西，还是得点滴做起 1、where语句的书写，当有多个查询条件时，sql是按照从右往左的顺序进行执行，也就是说写在最后的条件会最早被执行，这就意味着过滤数据量最多的 添加应该写在最后，这样才能在性能上达到最优 2、join语句，如果A表1000w，B表30条记录，则应该是A join B，sql执行会以B为准去关联A，性能显著 3、表变量和临时表

今天我们从语句的一些优化写法及一些简单优化方法做一个介绍。这对于很多开发人员来说还是很有用的！为了方便阅读给出前文链接： SQL SERVER全面优化-------Expert for SQL Server 诊断系列 http://www.cnblogs.com/double-K/p/5538249.html 首先还是贴出我的座驾 　　　　 好的语句就像这辆车，跑的又快又帅气！今天这里介绍一些技巧让你可以改装一下自己的车！ 重中之重---语句执行顺序 在QQ群和人聊天的时候突然有位群友说：我才知道原来语句走索引是按照select 的字段筛选的！ 振振有词，非常肯定！另一个群友反问update呢 ？ 看起来很小白的问题，但确实让我很震惊！所以我们先看看语句的执行顺序 如果我没记错这是《SQL SERVER 2005技术内幕--查询》这本书的开篇第一章第一节。书的作者也要让读者首先了解语句是怎么样的一个执行顺序，因为不知道顺序何谈写个好语句？ 查询的逻辑执行顺序： (1) FROM < left_table> (2) ON < join_condition> (3) < join_type> JOIN < right_table> (4) WHERE < where_condition> (5) GROUP BY < group_by_list> (6) WITH {cube |

一、介绍： 在数据库的开发过程中，经常会遇到复杂的业务逻辑和对数据库的操作，这个时候就会用SP来封装数据库操作。如果项目的SP较多，书写又没有一定的规范，将会影响以后的系统维护困难和大SP逻辑的难以理解，另外如果数据库的数据量大或者项目对SP的性能要求很，就会遇到优化的问题，否则速度有可能很慢，经过亲身经验，一个经过优化过的SP要比一个性能差的SP的效率甚至高几百倍。 　 　　二、内容： 　 　　1、开发人员如果用到其他库的Table或View，务必在当前库中建立View来实现跨库操作，最好不要直接使用“databse.dbo.table_name”，因为sp_depends不能显示出该SP所使用的跨库table或view，不方便校验。　　 　　2、开发人员在提交SP前，必须已经使用set showplan on分析过查询计划，做过自身的查询优化检查。 　 　　3、高程序运行效率，优化应用程序，在SP编写过程中应该注意以下几点： 　　 　　a)SQL的使用规范： 　　　i.　尽量避免大事务操作，慎用holdlock子句，提高系统并发能力。 　　　ii.　尽量避免反复访问同一张或几张表，尤其是数据量较大的表，可以考虑先根据条件提取数据到临时表中，然后再做连接。 　　　iii.　尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该改写；如果使用了游标

简述过程 1.从excel导入到数据库。 2.导入方法：bcp导入法 3.注意事项： （1）检查文件的信息（大小、格式、。。 (2) 从excel导入到一张临时表(自己代码创建的一张数据库) (3) 从临时表导入到虚表 (4)虚表导入实体表 详细说明 1.从excel导入到数据库。 2.导入方法：bcp导入法 这是一种导入的方法，也可以采用其他的方式 3.注意事项： （1）检查文件的信息（大小、格式、。。） (2) 从excel导入到一张临时表(自己代码创建的一张数据库) 这张表格，一般是存你导入的表格的基本字段和需要添加的一些字段（预设的字段）， (3) 从临时表导入到虚表 判断一些基本的业务需求： 判断导入的字段信息是不是在数据库存在，表格存不存在记录重复，表格内字段间是不是逻辑有问题，是不是要处理同名的问题 例子：导入学校特色班学生 你可能要判断导入的学员是不是该学校的学生? 导入班级的信息是不是在数据库内？ 导入的记录中是不是有重复？ 是不是要处理同名的学生问题？ (4)虚表导入实体表 就是将表格的信息插入数据库表格里面的表格，先可能要插入关联的表格，然后插入对应的主表信息 可能遇到的问题 1.GridView编辑状态下的dropdownlist 2.怎么解决同名的问题 来源： https://www.cnblogs.com/Cristic-MeiFen/p/3738056

在数据库的开发过程中，经常会遇到复杂的业务逻辑和对数据库的操作，这个时候就会用SP来封装数据库操作。如果项目的SP较多，书写又没有一定的规范，将会影响以后的系统维护困难和大SP逻辑的难以理解，另外如果数据库的数据量大或者项目对SP的性能要求很，就会遇到优化的问题，否则速度有可能很慢，经过亲身经验，一个经过优化过的SP要比一个性能差的SP的效率甚至高几百倍。 内容： 1、开发人员如果用到其他库的Table或View，务必在当前库中建立View来实现跨库操作，最好不要直接使用“databse.dbo.table_name”，因为sp_depends不能显示出该SP所使用的跨库table或view，不方便校验。 2、开发人员在提交SP前，必须已经使用set showplan on分析过查询计划，做过自身的查询优化检查。 3、高程序运行效率，优化应用程序，在SP编写过程中应该注意以下几点： a) SQL的使用规范： i. 尽量避免大事务操作，慎用holdlock子句，提高系统并发能力。 ii. 尽量避免反复访问同一张或几张表，尤其是数据量较大的表，可以考虑先根据条件提取数据到临时表中，然后再做连接。 iii.尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该改写；如果使用了游标，就要尽量避免在游标循环中再进行表连接的操作。 iv. 注意where字句写法

InnoDB存储引擎物理存储结构 ibdata1 : 系统数据字典信息(统计信息)，UNDO表空间等数据 ib_logfile0 ~ ib_logfile1 : REDO日志文件，事务日志文件。 ibtmp1 : 临时表空间磁盘位置，存储临时表 frm : 存储表的列信息 ibd : 表的数据行和索引 共享表空间 需要将所有数据存储到同一个表空间中 ,管理比较混乱 5.5 版本出现的管理模式, 也是默认的管理模式。 5.6 版本, 共享表空间保留，只用来存储:数据字典信息,undo,临时表。 5.7 版本, 临时表被独立出来了 8.0 版本, undo也被独立出去了 select @@innodb_data_file_path; +-------------------------+ | @@innodb_data_file_path | +-------------------------+ | ibdata1:12M:autoextend | +-------------------------+ # 这里的目录是 my.cnf 中 datadir定义的目录 mysql> show variables like '%extend%'; +-----------------------------+-------+ | Variable_name | Value | +-----

　　谈到服务器性能，可能第一个从脑中蹦出来的是：查询速度？这确实是我们最常接触的方面，但性能其实还包括例如CPU利用率、可扩展性等很多方面。通过总结发现，不管修改的是哪一方面，最终都在影响一个量：时间。因此不妨将性能定义为： 完成任务所需时间的度量( 性能即响应时间 ) 。那什么是优化呢？如果认为优化是降低CPU使用率 那么此时可能你的任务需要更长的时间来完成。如果认为是提升了每次查询(select,update,delete,insert等)的量，这其实只是吞吐量的优化，此时你的CPU的压力可能已经增大了。因此我们 只能假设性能优化是在一定的工作负载下尽可能的降低响应时间。 最后我们将实际的讨论两种类型的性能剖析： 基于执行时间的分析 和 基于等待的分析 基于执行时间的分析：什么任务的执行时间最长 基于等待的分析：判断任务在什么地方被阻塞的时间最长 1、剖析全局性能 性能优化的前提当然是我们得知道哪出了问题，通常可以通过慢日志和pt_query_digest进行分析,对于应用程序我们则可以使用new Relic、xhprof、xdebug、Ifp(Instrumentation-for-php)来进行检测。当然对于性能分析我们不能时时进行检测，因为大量检测IO本身对应用会有影响。可以通过以下语句来控制频率： <?php $profile_enable = mt_rand(0,

查询学习课程”python”比课程 “java” 成绩高的学生的学号; – 思路： – 获取所有有python课程的人（学号，成绩） - 临时表 – 获取所有有java课程的人（学号，成绩） - 临时表 – 根据学号连接两个临时表： – 学号 | 物理成绩 | 生物成绩 – 然后再进行筛选 12345 select A.s_id from (select s_id, num as python from score left join course on score.c_id = course.c_id where course.c_name = 'python') as A left join (select s_id, num as java from score left join course on score.c_id = course.c_id where course.c_name = 'java') as B on A.s_id = B.s_id where A.python > B.java; 查询平均成绩大于65分的同学的姓名和平均成绩(保留两位小数); 12345 SELECT student.s_name as names, round(AVG(score.num), 2) as averageFROM student, scoreWHERE student

“Can not connect to MySQL server. Too many connections”-mysql 1040错误， 这是因为访问MySQL且还未释放的连接数目已经达到MySQL的上限。通常，mysql的最大连接数默认是100, 最大可以达到16384 第一种：命令行修改。 mysql>mysql -uuser -ppassword(命令行登录MySQL) mysql>show variables like 'max_connections';(查可以看当前的最大连接数) msyql>set global max_connections=1000;(设置最大连接数为1000，可以再次查看是否设置成功) mysql>exit(推出) 这种方式有个问题，就是设置的最大连接数只在mysql当前服务进程有效，一旦mysql重启，又会恢复到初始状态。 因为mysql启动后的初始化工作是从其配置文件中读取数据的，而这种方式没有对其配置文件做更改 第二种：修改配置文件。 这种方式说来很简单，只要修改MySQL配置文件my.ini 或 my.cnf的参数max_connections， 　将其改为max_connections=1000，然后重启MySQL即可。但是有一点最难的就是my.ini这个文件在哪找。 通常有两种可能，一个是在安装目录下（这是比较理想的情况）