临时表

导读 MySQL是一个开放源码的小型关联式数据库管理系统，开发者为瑞典MySQL AB公司。目前MySQL被广泛地应用在Internet上的中小型网站中。由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，许多中小型网站为了降低网站总体拥有成本而选择了MySQL作为网站数据库。 可能有人会惊奇MySQL为何从5.x一下跳跃到了8.0。事实上，MySQL 5.x系列已经延续了很多年，从被Oracle收购之前就是5.1，而收购之后一直维持在5.x，比如5.5，5.6，5.7等等。其实，如果按照原本的发布节奏，可以把5.6.x当成6.x，5.7.x当成7.x。所以，只是换了版本命名方式而已。 MySQL 8.0.0亮点 事务住数据字典，完全脱离了MylSAM存储引擎 真正将数据字典放到了1nnoOB中的一些表中，夕J长下再需要FRM、TRG、pAR文件啦！Inf rmationSchema现在以数据字典表的一个视图出现。原则上可以完全不需要MylSAM数据 表类型了，所有的系统表都可以放到Inn0OB之中。 SQL角色 角色是一系列叹限的集台。可以创建角色，给莫个用户授子和去除角色。这对于权限管理 很方便。 uttsmb4字芍集将成为默认字符集，并支持Unicode 9 默认字符集将从1atinl改为uttsmb4，默认走序collatlon将从latlnl_swedish

case：下面的一条sql语句，导致mysql实例内存暴涨： 　　 select * from tables where table_name not in(select table_name from partitions group by table_name having count(*)>1 ); 　　 mysql 5.5， 1w+的innodb表。 下面看下调查的结果： 1. sql的执行情况以及内存分配： step1 ： 构造information_schema.tables临时表 1.1 构造临时表tables结构： 说明：func=create_schema_table; engine=heap 内存: tables是heap引擎的表，临时构造，使用堆内存；语句结束close_tmp_tables释放。 1.2 填充临时表tables数据：一共由三类表来填充tables的内存 1. memory 引擎： 说明：information_schema下的表，创建临时table， 内存： 使用堆内存，填充完数据后 close_tmp_tables，释放内存。 2. mysiam 引擎： 说明：information_schema下一部分表，是mysiam引擎的临时表。 内存： 使用堆内存，创建磁盘临时文件，close_tmp_tables，释放内存，删除临时文件。 3.

MySQL 8.0 简介 MySQL 5.7 到 8.0，Oracle 官方跳跃了 Major Version 版本号，随之而来的就是在 MySQL 8.0 上做了许多重大更新，在往企业级数据库的路上大步前行，全新 Data Dictionary 设计，支持 Atomic DDL，全新的版本升级策略，安全和账号管理加强，InnoDB 功能增强等，目前小版本已经 release 到 8.0.16，新的功能仍然在持续推出。 RDS MySQL 8.0 产品是阿里云推出的 MySQL 系列云产品之一，使用完全兼容 MySQL 8.0 的阿 里云 AliSQL 8.0 分支，除了官方在 MySQL 8.0 推出的全新功能外，AliSQL 沉淀了许多在 Alibaba 集团电商业务和云上几十万客户在使用 MySQL 过程中遇到的问题和需求，以此来加固AliSQL, 提升 AliSQL 的性能和稳定性。 下面分别对 MySQL 8.0 和 AliSQL 8.0 相关的版本和功能做简短的介绍: MySQL 8.0 版本更新 1. 数据字典 MySQL 8.0 摒弃了 Server Layer 定义的 FRM 文件和其它非事务表，使用了一组 InnoDB 表来 保存数据字典，支持事务特性。 2. Atomic DDL 在 Data Dictionary 支持事务特性的基础上，8.0 增加了一个

sudo find / -name php.ini 如果没找到 cd /Private/etc 可以找到php.ini.default cp php.ini.default php.ini 复制一份 2017-03-23T03:03:00.557711Z 1 [Note] A temporary password is generated for root@localhost: nRWip6C+C3q& If you lose this password, please consult the section How to Reset the Root Password in the MySQL reference manual. 现在你就可以通过mysql -uroot -p登录mysql了，会让你输入密码，就是pic3上的>fj... 登录成功后，你可以通过下面的命令修改密码 SET PASSWORD FOR 'root'@'localhost' = PASSWORD('newpass'); mysqladmin -u root -p create RUNOOB 以上命令执行成功后会创建 MySQL 数据库 RUNOOB。 [root@host]# mysqladmin -u root -p drop RUNOOBEnter password:******

java性能调优 一、代码优化 1、使用递归调用时，如果过多的调用容易造成java.lang.StackOverflowError即栈溢出和程序执行过慢。这是一个潜在Bug和影响程序执行效率问题，需要谨慎使用。原因：每次递归调用时会向栈中push当前方法的运行状态（现场），而Java栈内存的使用超过限制的大小时，程序会出现栈异常。 2、及时关闭流。Java编程过程中，进行数据库连接、I/O 流操作时务必小心，在使用完毕后，及时关闭以释放资源。因为对这些大对象的操作会造成系统大的开销，稍有不慎，将会导致严重的后果。 3、注意方法、类文件中的代码量，适度分离。 4、使用基本类型定义变量时，千万注意该变量值可能为null的情况，此时建议使用对应的包装类来定义变量。 5、循环体内不要使用 “+” 进行字符串拼接，而直接使用 StringBuilder 不断 append。通过查看反编译以后的代码，可以发现，在字符串常量在拼接过程中，是将 String 转成了 StringBuilder 后，使用其 append() 方法进行处理的。 6、循环内不要不断创建对象引用。 7、尽量采用懒加载的策略，即在需要的时候才开始创建变量和对象等。 8、将一些需要变动的配置或文案写在属性文件中。 9、后端接口需要提供必要的校验，不要过于依赖前端校验。 10、基于效率和类型检查的考虑，应该尽可能使用 数组

导入数据 全量导入kudu 先用sqoop把关系数据库数据导入临时表，再用impala从临时表导入kudu目标表 注意：由于sqoop从关系型数据直接以parquet格式导入hive会有问题，这里默认hive的表都是text格式；每次导完到临时表，需要做invalidate metadata 表操作，不然后面直接导入kudu的时候会查不到数据 客户端 除了查询，建议所有impala操作都在impala-shell而不在hue上面执行 参数 memory_limit_hard_bytes ：impala并发写入kudu的时候，数据量比较大的时候，kudu配置参数 memory_limit_hard_bytes能大点就大点，因为kudu写入首先保存再内存里面，到一定阀值才溢写到磁盘，这个是直接最能提高写的方法； maintenance_manager_num_threads ：当然不是所有机器都有那么多资源，可以把maintenance_manager_num_threads 这个参数稍微调大，需要调试，提高数据从内存写入磁盘的效率 impala查询kudu 首先所有表做完全量的ETL操作，必须得执行compute stats 表名，不然impala执行sql生成的计划执行数评估的内存不准确，容易评估错误导致实际执行不了 kudu表最好不要做任何压缩，保证原始扫描性能发挥最好

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 http://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

类似mssql中的临时表变量一样,在postgresql 中可以使用with 来定义临时表变量 WITH regional_sales AS ( --reginal_sales 是临时表变量的表名 SELECT region, SUM(amount) AS total_sales FROM orders GROUP BY region ), top_regions AS ( -- 这是定义的第二个临时表变量 SELECT region FROM regional_sales WHERE total_sales > (SELECT SUM(total_sales)/10 FROM regional_sales) ) -- 主语句 SELECT region, product, SUM(quantity) AS product_units, SUM(amount) AS product_sales FROM orders WHERE region IN (SELECT region FROM top_regions) -- 使用临时表变量 GROUP BY region, product; 补充:使用临时表变量查询,可以使代码更清晰,并且避免编写重复的代码. 来源： https://www.cnblogs.com/qianxunman/p/12210258.html

一些看似简单的数据操作，当作用于海量数据集时，就会出现“意料之外，却在情理之中”的问题，海量数据操作，需要采用特殊方法，才能“曲径通幽”。在删除海量数据时，需要注意日志的增长，索引碎片的增加和数据库的恢复模式，特别是利用大容量日志操作，来减少日志的增长和提高数据插入的速度。对于大数据去重，通过一些小小的改进，比如创建索引，设置忽略重复值选项等，能够提高去重的效率。 一，从海量数据中删除数据 从海量数据表中删除一半数据，看似简单，使用delete命令，如果真这么干，SQL Server产生的事务日志暴增，估计会把服务器硬盘爆掉。数据库的恢复模式会影响日志文件的增长，在删除海量数据时，根据采用的方法，相应地把恢复模式设置为simple，或bulk_logged 模式，能够在很大程度上减少删除操作产生的事务日志，从而避免日志暴增。 另外，在删除数据时，把表上的多余索引删除（注意，是删除多余的索引），只保留一个必需的索引；在数据删除完成之后，再重建索引，能够提高数据删除操作的性能。有人做过实验，从存储1.6亿条记录的大表中删除数据，每删除400万条要消耗1.5 - 3小时，越到后面速度越慢，为什么？这是因为，每次删除数据时，数据库都要相应地更新索引，这是很慢的硬盘 IO操作，并且，越到后面，索引碎片越多，更新索引就越慢，这就是在删除400万条记录时，一开始只消耗1.5小时

--drop table #Tmp --删除临时表#TmpCREATE TABLE #Tmp --创建临时表#Tmp( AppliedIndustryNO int IDENTITY (1,1) not null, --创建列ID,并且每次新增一条记录就会加1 AppliedIndustryName varchar(50), primary key (AppliedIndustryNO) --定义AppliedIndustryNO为临时表#Tmp的主键 );Select * from #Tmp --查询临时表的数据truncate table #Tmp --清空临时表的所有数据和约束Declare @AppliedIndustryName Varchar(500) --用来记录名称Declare @Str NVarchar(4000) --用来存放查询语句Declare @Count int --求出总记录数 Declare @i intSet @i = 0 Select @Count = Count(Distinct(AppliedIndustryName)) from #TmpWhile @i < @Count Begin Set @Str = 'Select top 1 @AppliedIndustryName = AppliedIndustryName from #Tmp