临时表

一、order by的原理 1、利用索引的有序性获取有序数据 当查询语句的 order BY 条件和查询的执行计划中所利用的 Index 的索引键（或前面几个索引键）完全一致，且索引访问方式为 range,ref 或者 index 的时候，MySQL 可以利用索引顺序而直接取得已经排好序的数据。这种方式的 order BY 基本上可以说是最优的排序方式了,因为 MySQL 不需要进行实际的排序操作，需要注意的是使用索引排序也有很多限制。 当对连接操作进行排序时，如果ORDER BY仅仅引用第一个表的列，MySQL对该表进行filesort操作，然后进行连接处理，此时，EXPLAIN输出“Using filesort”；否则，MySQL必须将查询的结果集生成一个临时表，在连接完成之后进行filesort操作，此时，EXPLAIN输出“Using temporary;Using filesort”。 注意： MySQL在查询时最多只能使用一个索引。因此，如果WHERE条件已经占用了索引，那么在排序中就不使用索引了 mysql> show create table test \G *************************** 1. row *************************** Table: test Create Table: CREATE TABLE

数据库基本概念：区、页、行 区 ：SQL Server中管理空间的基本单位。一个区大小为64KB，是八个物理上连续的页。SQL Server中每MB有16个区。一旦一个区被存储满，SQL Server将分配一个区给下一条数据。 页 ：SQL Server中存储数据的基本单位，是区的分配单元。一个页大小为8KB。是SQL Server 每次读取和写入数据的最小单位。页的类型有数据页，索引页，文本页等等。 行 ：行存储于页中，一行一般最多占满一页，也就是8KB，但也有些VARCHAR(MAX),TEXT,IMAGE类型的字段，可以跨越多页存储，一行最大2GB。 收缩数据库 数据库中每个文件都可以通过删除未使用的页的方法来收缩。数据文件和事务日志文件都可以收缩。数据库收缩分为手动收缩和通过数据库设置自动收缩。 设置数据库自动收缩 数据库引擎会定期检查每个数据库的空间使用情况，自动收缩有可用空间的数据库。 ALTER DATABASE test SET AUTO_SHRINK ON; 设置关闭自动收缩 ALTER DATABASE test SET AUTO_SHRINK OFF; 数据库手动收缩 DBCC SHRINKDATABASE(test,10); GO 或者使用如下命令： USE test DBCC SHRINKFILE('test',0,TRUNCATEONLY);

一： MYSQL安装和基本配置 在linux上安装，可以用包管理工具来安装，比较简单： RedHat 系列：yum -y install mysql mysql-server Debian系列：sudo apt-get install mysql mysql-server 安装之后不知道mysql装到哪了怎么办，用whereis mysql 命令来找一下。 先找到mysql的默认配置文件。一般来说，安装后有这么几个备选的配置： 1 my-huge.cnf my-innodb-heavy-4G.cnf my-large.cnf my-medium.cnf my-small.cnf　 就2014年的机器配置来说，咱们直接用my-huge.cnf。把my-huge.cnf 复制到/etc/下，改名my.cnf。配置文件就有了， 然后启动mysql： /etc/init.d/mysqld start 。 安装之后默认的帐号是root, 密码为空。咱们要做的第一件事是改root密码。 进入mysql：mysql -uroot -p 选择数据库： use mysql 改密码： UPDATE user SET Password = PASSWORD(‘xxxx’) WHERE user = ‘root’; 刷新权限： FLUSH PRIVILEGES; 现在数据库装好了， 帐号和权限也设置了

大数据量数据库优化 一、数据库结构的设计 如果不能设计一个合理的数据库模型，不仅会增加客户端和服务器段程序的编程和维护的难度，而且将会影响系统实际运行的性能。所以，在一个系统开始实施之前，完备的数据库模型的设计是必须的。 在一个系统分析、设计阶段，因为数据量较小，负荷较低。我们往往只注意到功能的实现，而很难注意到性能的薄弱之处，等到系统投入实际运行一段时间后，才发现系统的性能在降低，这时再来考虑提高系统性能则要花费更多的人力物力，而整个系统也不可避免的形成了一个打补丁工程。 所以在考虑整个系统的流程的时候，我们必须要考虑，在高并发大数据量的访问情况下，我们的系统会不会出现极端的情况。（例如：对外统计系统在7月16日出现的数据异常的情况，并发大数据量的的访问造成，数据库的响应时间不能跟上数据刷新的速度造成。具体情况是：在日期临界时（00：00：00），判断数据库中是否有当前日期的记录，没有则插入一条当前日期的记录。在低并发访问的情况下，不会发生问题，但是当日期临界时的访问量相当大的时候，在做这一判断的时候，会出现多次条件成立，则数据库里会被插入多条当前日期的记录，从而造成数据错误。），数据库的模型确定下来之后，我们有必要做一个系统内数据流向图，分析可能出现的瓶颈。 为了保证数据库的一致性和完整性，在逻辑设计的时候往往会设计过多的表间关联，尽可能的降低数据的冗余。（例如用户表的地区

数据库在通过连接两张或多张表来返回记录时，都会生成一张中间的临时表，然后再将这张临时表返回给用户。 在使用left jion时，on和where条件的区别如下： 1、 on条件是在生成临时表时使用的条件，它不管on中的条件是否为真，都会返回左边表中的记录。 2、where条件是在临时表生成好后，再对临时表进行过滤的条件。这时已经没有left join的含义（必须返回左边表的记录）了，条件不为真的就全部过滤掉。 假设有两张表： 表1：tab2 id size 1 10 2 20 3 30 表2：tab2 size name 10 AAA 20 BBB 20 CCC 两条SQL: 1、select * form tab1 left join tab2 on (tab1.size = tab2.size) where tab2.name=’AAA’ 2、select * form tab1 left join tab2 on (tab1.size = tab2.size and tab2.name=’AAA’) 第一条SQL的过程： 1、中间表 on条件: tab1.size = tab2.size tab1.id tab1.size tab2.size tab2.name 1 10 10 AAA 2 20 20 BBB 2 20 20 CCC 3 30 (null) (null) |

网上关于 SQL优化的教程很多，但是比较杂乱。近日有空整理了一下，写出来跟大家分享一下，其中有错误和不足的地方，还请大家纠正补充。 1.对查询进行优化，要尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如： select id from t where num is null 最好不要给数据库留 NULL，尽可能的使用 NOT NULL填充数据库。备注、描述、评论之类的可以设置为 NULL，其他的，最好不要使用NULL。 不要以为 NULL 不需要空间，比如：char(100) 型，在字段建立时，空间就固定了， 不管是否插入值（NULL也包含在内），都是占用 100个字符的空间的，如果是varchar这样的变长字段， null 不占用空间。 可以在 num上设置默认值0，确保表中num列没有null值，然后这样查询： select id from t where num = 0 3.应尽量避免在 where 子句中使用 != 或 <> 操作符，否则将引擎放弃使用索引而进行全表扫描。 4.应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描，如： select

1.1 还原使用mysqldump命令备份的数据库的语法如下： 　　mysql -u root -p [dbname] < backup.sq 　　示例： mysql -u root -p < C:\backup.sql 1.2还原直接复制目录的备份 　　 通过这种方式还原时，必须保证两个MySQL数据库的版本号是相同的。MyISAM类型的表有效，对于InnoDB类型的表不可用，InnoDB表的表空间不能直接复制 2. 还原增量binlog的方法 2.1 时间点的恢复建立在一下规则的基础上: 1 mysql服务器需要开启二进制日志--log-bin 查看所有binlog文件 mysql> SHOW BINARY LOGS; 查看当前binlog文件信息（包含文件名，当前位置等） mysql> SHOW MASTER STATUS; 2 mysqlbinlog工具将binary log文件由二进制转换为可读的文本文件，可以选择基于时间或位置的事件。 3 从binary log文件中执行事件会导致数据的修改，表示要重做数据。命令为： [root@localhost /]# mysqlbinlog binlog_files | mysql -u root -p 4 查看binlog的时间及位置信息我们可以讲binlog内容输出到终端或文本文件 [root@localhost /]#

查询的逻辑执行顺序 FROM < left_table> ON < join_condition> < join_type> JOIN < right_table> WHERE < where_condition> GROUP BY < group_by_list> WITH {cube | rollup} HAVING < having_condition> SELECT DISTINCT ORDER BY < order_by_list> < top_specification> < select_list> 标准的SQL 的解析顺序为: .FROM 子句 组装来自不同数据源的数据 .WHERE 子句 基于指定的条件对记录进行筛选 .GROUP BY 子句 将数据划分为多个分组 .使用聚合函数进行计算 .使用HAVING子句筛选分组 .计算所有的表达式 .使用ORDER BY对结果集进行排序 执行顺序 FROM：对FROM子句中前两个表执行笛卡尔积生成虚拟表vt1 ON:对vt1表应用ON筛选器只有满足< join_condition> 为真的行才被插入vt2 OUTER(join)：如果指定了 OUTER JOIN保留表(preserved table)中未找到的行将行作为外部行添加到vt2

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 如何 SELECT * INTO [temp table] FROM [stored procedure] 进行 SELECT * INTO [temp table] FROM [stored procedure] ？ 不是 FROM [Table] ，也没有定义 [temp table] ？ 从 BusinessLine Select 所有数据到 tmpBusLine 可以正常工作。 select * into tmpBusLine from BusinessLine 我正在尝试相同的方法，但是使用返回数据的 stored procedure 并不完全相同。 select * into tmpBusLine from exec getBusinessLineHistory '16 Mar 2009' 输出信息： 消息156，级别15，状态1，第2行关键字“ exec”附近的语法错误。 我已经阅读了几个创建与输出存储过程具有相同结构的临时表的示例，该示例工作正常，但是最好不要提供任何列。 #1楼 如果您存储的proc的结果表太复杂而无法手动键入“ create table”语句，并且您不能使用OPENQUERY或OPENROWSET，则可以使用sp_help为您生成列和数据类型的列表。 获得列列表后

MySQL面试总结 # MySQL的存储引擎 `MyISAM`（默认表类型）：非事务的存储引擎，基于传统的`ISAM`（有索引的顺序访问方法）类型，是存储记录和文件的标准方法，不是事务安全，不支持外键，适用于频繁的查询。表锁，不会出现死锁，适合小数据和小并发。 - 为什么不会出死锁？（没有事务就不会继续持有锁） 答：因为`MyISAM`再查询的时候，会同时锁定这个`sql`里面所有用到的表（获取锁的顺序是一致的），不局限与一张表，再写锁又重叠时，就得等待。 **注意：【`MySQL5.5`之前默认的是`MyISAM`引擎了，5.5之后的版本默认都是`innodb`作为存储引擎】** `innodb`：支持事务安全的存储引擎，适用于插入和更新，支持外键，行锁，事务。适合大数据，大并发。特别是针对多个并发和`QPS`较高的情况。 - `QPS：`就是每秒查询率，`QPS`是对一个特定服务器再规定时间内能处理多少流量的衡量标准。 - `TPS：`就是每秒传输处理的事务个数。 - `innodb`的行锁模式：共享锁，排他锁，意向共享锁（表锁），意向排他锁（表锁），间隙锁。（注意：如果`sql`语句没有使用索引，`innodb`不能确定操作的行时，使用意向锁（表锁））。 - 死锁问题 - 什么是死锁？ 死锁就是当俩个事务都需要获取对方持有的排他锁才能完成事务的时候，就导致了循环锁等待