‘壹’ sql Server 怎样使用SQL输出建表语句
方法/步骤
1
首先找到这个数据库，右击-》任务-》生成脚本
2
然后就进入了生成脚本的向导，点击下一步。
这里会有很多个数据库，我们选择自己想要建表的那个数据库，选择以后点击下一步。
这里可以选择编写所有脚本，也可以不选直接下一步。
在这里，因为我们只是建表，所以我们把表勾上，不要勾选全部，不然下面就不能继续了。
这里我们选择要导出sql语句的表，勾上以后点击下一步。
在这个界面，我们选择将脚本保存到文件，然后浏览要存放的位置，还能选择文本的编码方式，一般默认是Unicode编码方式。。
选择生成的文件的名字，并选择保存的路径。
点击浏览选择保存后，点击完成。
在这个界面你什么都不用管，点击完成就行。
点击完成后，会看到生成脚本的进度，生成的状态。
最后我们在保存的路径下找到这个文件，用记事本打开看看，可以看到这个建表的sql语句。证明我们导出的建表语句是成功的。
‘贰’ sql中OLTP和ALTP表示什么
OLAP是联机分析处理
OLTP是联机事务处理
OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观、易懂的查询结果。
OLTP是传统的关系型数据库的主要应用模式，主要面对基本的、日常的事务处理；比如数据库记录的增、删、改、查。
‘叁’ SQL Server 2014 的集成内存 OLTP 有什么战略意义
SQL Server 2014 的集成内存 OLTP 有什么战略意义
Hekaton 的主要创新是：
1. MVCC取代了latch, 让交易阻塞的时间尽可能短
2. 使用了一种在内存上性能更好的Bw-Tree实现
‘肆’ Microsoft SQL Server和Sybase ASE及Sybase ASE哪些是OLTP数据库啊
Sybase ASE的早期版本为SYBASE 10 及SYABSE 11，随后改为Sybase ASE。MS的SQL SERVER 的早期版本也是由Sybase演化而来的，他们都是OLTP型数据库。
‘伍’ 如何写出高性能SQL语句
优化SQL查询：如何写出高性能SQL语句
1、首先要搞明白什么叫执行计划？
执行计划是数据库根据SQL语句和相关表的统计信息作出的一个查询方案，这个方案是由查询优化器自动分析产生欀如一条SQL语句如果用来从一个10万条记录的表中查1条记录，那查询优化器会选择“索引查找”方式，如果该表进行了归档，当前只剩下5000条记录了，那查询优化器就会改变方案，采用 “全表扫描”方式。
可见，执行计划并不是固定的，它是“个性化的”。产生一个正确的“执行计划”有两点很重要：
(1) SQL语句是否清晰地告诉查询优化器它想干什么？
(2) 查询优化器得到的数据库统计信息是否是最新的、正确的？
2、统一SQL语句的写法
对于以下两句SQL语句，程序员认为是相同的，数据库查询优化器认为是不同的。
select * from al
select * From al
其实就是大小写不同，查询分析器就认为是两句不同的SQL语句，必须进行两次解析。生成2个执行计划。
所以作为程序员，应该保证相同的查询语句在任何地方都一致，多一个空格都不行！
3、不要把SQL语句写得太复杂
我经常看到，从数据库中捕捉到的一条SQL语句打印出来有2张A4纸这么长。一般来说这么复杂的语句通常都是有问题的。我拿着这2页长的SQL语句去请教原作者，结果他说时间太长，他一时也看不懂了。可想而知，连原作者都有可能看糊涂的SQL语句，数据库也一样会看糊涂。
一般，将一个Select语句的结果作为子集，然后从该子集中再进行查询，这种一层嵌套语句还是比较常见的，但是根据经验，超过3层嵌套，查询优化器就很容易给出错误的执行计划。因为它被绕晕了。像这种类似人工智能的东西，终究比人的分辨力要差些，如果人都看晕了，我可以保证数据库也会晕的。
另外，执行计划是可以被重用的，越简单的SQL语句被重用的可能性越高。而复杂的SQL语句只要有一个字符发生变化就必须重新解析，然后再把这一大堆垃圾塞在内存里。可想而知，数据库的效率会何等低下。
4、使用“临时表”暂存中间结果
简化SQL语句的重要方法就是采用临时表暂存中间结果，但是，临时表的好处远远不止这些，将临时结果暂存在临时表，后面的查询就在tempdb中了，这可以避免程序中多次扫描主表，也大大减少了程序执行中“共享锁”阻塞“更新锁”，减少了阻塞，提高了并发性能。
5、 OLTP系统SQL语句必须采用绑定变量
select * from orderheader where changetime > ’2010-10-20 00:00:01′
select * from orderheader where changetime > ’2010-09-22 00:00:01′
以上两句语句，查询优化器认为是不同的SQL语句，需要解析两次。
如果采用绑定变量
select * from orderheader where changetime > @chgtime
@chgtime变量可以传入任何值，这样大量的类似查询可以重用该执行计划了，这可以大大降低数据库解析SQL语句的负担。一次解析，多次重用，是提高数据库效率的原则。
6、绑定变量窥测
事物都存在两面性，绑定变量对大多数OLTP处理是适用的，但是也有例外。
比如在where条件中的字段是“倾斜字段”的时候。
“倾斜字段”指该列中的绝大多数的值都是相同的，一张人口调查表，其中“民族”这列，90%以上都是汉族。那么如果一个SQL语句要查询30岁的汉族人口有多少，那“民族”这列必然要被放在where条件中。这个时候如果采用绑定变量@nation会存在很大问题。
试想如果@nation传入的第一个值是“汉族”，那整个执行计划必然会选择表扫描。然后，第二个值传入的是“布依族”，按理说“布依族”占的比例可能只有万分之一，应该采用索引查找。但是，由于重用了第一次解析的“汉族”的那个执行计划，那么第二次也将采用表扫描方式。这个问题就是着名的“绑定变量窥测”，建议对于“倾斜字段”不要采用绑定变量。
7、 只在必要的情况下才使用begin tran
SQL Server中一句SQL语句默认就是一个事务，在该语句执行完成后也是默认commit的。其实，这就是begin tran的一个最小化的形式，好比在每句语句开头隐含了一个begin tran，结束时隐含了一个commit。
有些情况下，我们需要显式声明begin tran，比如做“插、删、改”操作需要同时修改几个表，要求要么几个表都修改成功，要么都不成功。begin tran 可以起到这样的作用，它可以把若干SQL语句套在一起执行，最后再一起commit。好处是保证了数据的一致性，但任何事情都不是完美无缺的。Begin tran付出的代价是在提交之前，所有SQL语句锁住的资源都不能释放，直到commit掉。
可见，如果Begin tran套住的SQL语句太多，那数据库的性能就糟糕了。在该大事务提交之前，必然会阻塞别的语句，造成block很多。
Begin tran使用的原则是，在保证数据一致性的前提下，begin tran 套住的SQL语句越少越好！有些情况下可以采用触发器同步数据，不一定要用begin tran。
8、一些SQL查询语句应加上nolock
在SQL语句中加nolock是提高SQL Server并发性能的重要手段，在oracle中并不需要这样做，因为oracle的结构更为合理，有undo表空间保存“数据前影”，该数据如果在修改中还未commit，那么你读到的是它修改之前的副本，该副本放在undo表空间中。这样，oracle的读、写可以做到互不影响，这也是oracle 广受称赞的地方。
SQL Server 的读、写是会相互阻塞的，为了提高并发性能，对于一些查询，可以加上nolock，这样读的时候可以允许写，但缺点是可能读到未提交的脏数据。
使用 nolock有3条原则。
(1) 查询的结果用于“插、删、改”的不能加nolock ！
(2) 查询的表属于频繁发生页分裂的，慎用nolock ！
(3) 使用临时表一样可以保存“数据前影”，起到类似oracle的undo表空间的功能，
能采用临时表提高并发性能的，不要用nolock 。
9、聚集索引没有建在表的顺序字段上，该表容易发生页分裂
比如订单表，有订单编号orderid，也有客户编号contactid，那么聚集索引应该加在哪个字段上呢？对于该表，订单编号是顺序添加的，如果在orderid上加聚集索引，新增的行都是添加在末尾，这样不容易经常产生页分裂。然而，由于大多数查询都是根据客户编号来查的，因此，将聚集索引加在contactid上才有意义。而contactid对于订单表而言，并非顺序字段。
比如“张三”的“contactid”是001，那么“张三”的订单信息必须都放在这张表的第一个数据页上，如果今天“张三”新下了一个订单，那该订单信息不能放在表的最后一页，而是第一页！如果第一页放满了呢？很抱歉，该表所有数据都要往后移动为这条记录腾地方。
SQL Server的索引和Oracle的索引是不同的，SQL Server的聚集索引实际上是对表按照聚集索引字段的顺序进行了排序，相当于oracle的索引组织表。SQL Server的聚集索引就是表本身的一种组织形式，所以它的效率是非常高的。也正因为此，插入一条记录，它的位置不是随便放的，而是要按照顺序放在该放的数据页，如果那个数据页没有空间了，就引起了页分裂。所以很显然，聚集索引没有建在表的顺序字段上，该表容易发生页分裂。
曾经碰到过一个情况，一位哥们的某张表重建索引后，插入的效率大幅下降了。估计情况大概是这样的。该表的聚集索引可能没有建在表的顺序字段上，该表经常被归档，所以该表的数据是以一种稀疏状态存在的。比如张三下过20张订单，而最近3个月的订单只有5张，归档策略是保留3个月数据，那么张三过去的 15张订单已经被归档，留下15个空位，可以在insert发生时重新被利用。在这种情况下由于有空位可以利用，就不会发生页分裂。但是查询性能会比较低，因为查询时必须扫描那些没有数据的空位。
重建聚集索引后情况改变了，因为重建聚集索引就是把表中的数据重新排列一遍，原来的空位没有了，而页的填充率又很高，插入数据经常要发生页分裂，所以性能大幅下降。
对于聚集索引没有建在顺序字段上的表，是否要给与比较低的页填充率？是否要避免重建聚集索引？是一个值得考虑的问题！
10、加nolock后查询经常发生页分裂的表，容易产生跳读或重复读
加nolock后可以在“插、删、改”的同时进行查询，但是由于同时发生“插、删、改”，在某些情况下，一旦该数据页满了，那么页分裂不可避免，而此时nolock的查询正在发生，比如在第100页已经读过的记录，可能会因为页分裂而分到第101页，这有可能使得nolock查询在读101页时重复读到该条数据，产生“重复读”。同理，如果在100页上的数据还没被读到就分到99页去了，那nolock查询有可能会漏过该记录，产生“跳读”。
上面提到的哥们，在加了nolock后一些操作出现报错，估计有可能因为nolock查询产生了重复读，2条相同的记录去插入别的表，当然会发生主键冲突。
11、使用like进行模糊查询时应注意
有的时候会需要进行一些模糊查询比如
select * from contact where username like ‘%yue%’
关键词%yue%，由于yue前面用到了“%”，因此该查询必然走全表扫描，除非必要，否则不要在关键词前加%，
12、数据类型的隐式转换对查询效率的影响
sql server2000的数据库一的程序在提交sql语句的时候，没有使用强类型提交这个字段的值，由sql server 2000自动转换数据类型，会导致传入的参数与主键字段类型不一致，这个时候sql server 2000可能就会使用全表扫描。Sql2005上没有发现这种问题，但是还是应该注意一下。
13、SQL Server 表连接的三种方式
(1) Merge Join
(2) Nested Loop Join
(3) Hash Join
SQL Server 2000只有一种join方式——Nested Loop Join，如果A结果集较小，那就默认作为外表，A中每条记录都要去B中扫描一遍，实际扫过的行数相当于A结果集行数x B结果集行数。所以如果两个结果集都很大，那Join的结果很糟糕。
SQL Server 2005新增了Merge Join，如果A表和B表的连接字段正好是聚集索引所在字段，那么表的顺序已经排好，只要两边拼上去就行了，这种join的开销相当于A表的结果集行数加上B表的结果集行数，一个是加，一个是乘，可见merge join 的效果要比Nested Loop Join好多了。
如果连接的字段上没有索引，那SQL2000的效率是相当低的，而SQL2005提供了Hash join，相当于临时给A，B表的结果集加上索引，因此SQL2005的效率比SQL2000有很大提高，我认为，这是一个重要的原因。
总结一下，在表连接时要注意以下几点：
(1) 连接字段尽量选择聚集索引所在的字段
(2) 仔细考虑where条件，尽量减小A、B表的结果集
(3) 如果很多join的连接字段都缺少索引，而你还在用SQL Server 2000，赶紧升级吧。
‘陆’ 已有数据库升级sqlserver2014 可以支持内存oltp吗
：CTP1已经可以下载了。 感觉这次数据库引擎确实有了不少的增强，之前很多人抱怨MS只重视BI不重视数据库引擎。 一），Hekaton 支持OLTP的in-memory 数据库引擎
‘柒’ postgreSQL的简单介绍
postgreSQL是一款先进的开源数据库，拥有非常齐全的自由软件的对象-关系型数据库管理系统（ORDBMS），可面向企业复杂SQL的OLTP业务场景，支持多项企业级功能，能解决使用数据库的各种难题。
PostgreSQL的优势有很多。它是一个免费的对象-关系数据库服务器(ORDBMS)，在灵活的BSD许可证下发行。
postgreSQL的特征
函数：通过函数，可以在数据库服务器端执行指令程序。
索引：用户可以自定义索引方法，或使用内置的 B 树，哈希表与 GiST 索引。
触发器：触发器是由SQL语句查询所触发的事件。如：一个INSERT语句可能触发一个检查数据完整性的触发器。触发器通常由INSERT或UPDATE语句触发。 多版本并发控制：PostgreSQL使用多版本并发控制（MVCC，Multiversion concurrency control）系统进行并发控制，该系统向每个用户提供了一个数据库的"快照"，用户在事务内所作的每个修改，对于其他的用户都不可见，直到该事务成功提交。
规则：规则（RULE）允许一个查询能被重写，通常用来实现对视图（VIEW）的操作，如插入（INSERT）、更新（UPDATE）、删除（DELETE）。
数据类型：包括文本、任意精度的数值数组、JSON 数据、枚举类型、XML 数据等。全文检索：通过 Tsearch2 或 OpenFTS，8.3版本中内嵌 Tsearch2。
NoSQL：JSON，JSONB，XML，HStore 原生支持，至 NoSQL 数据库的外部数据包装器。
数据仓库：能平滑迁移至同属postgreSQL生态的GreenPlum，DeepGreen，HAWK 等，使用 FDW 进行 ETL。
‘捌’ OLTP和OLAP有何区别
1、适用人员不同：OLTP主要供基层人员使用，进行一线业务操作。OLAP则是探索并挖掘数据价值，作为企业高层进行决策的参考。
2、面向内容不同：OLTP面向应用，OLAP面向主题；
4、数据特点不同：OLTP的数据特点是当前的、最新的、细节的, 二维的、分立的；而OLTP则是历史的, 聚集的, 多维的，集成的, 统一的；
5、存取能力不同：OLTP可以读/写数十条记录，而OLAP则可以读上百万条记录；
6、工作事件的复杂度不同：OLTP执行的是简单的事务，而OLAP执行的是复杂任务；
7、可承载用户数量不同：OLTP的可承载用户数量为上千个，而OLAP则是上百万个；
8、DB大小不同：OLTP的DB 大小为100GB，而OLAP则可以达到100TB；
9、执行时间要求不同：OLTP具有实时性，OLAP对时间的要求不严格。
(8)sqloltp扩展阅读：
OLTP与OLAP的实际应用
OLAP工具是针对特定问题的联机数据访问与分析。它通过多维的方式对数据进行分析、查询和报表。维是人们观察数据的特定角度。
例如，一个企业在考虑产品的销售情况时，通常从时间、地区和产品的不同角度来深入观察产品的销售情况。这里的时间、地区和产品就是维。
这些维的不同组合和所考察的度量指标构成的多维数组则是OLAP分析的基础，可形式化表示为（维1，维2，……，维n，度量指标），如（地区、时间、产品、销售额）。
多维分析是指对以多维形式组织起来的数据采取切片（Slice）、切块（Dice）、钻取（Drill-down和Roll-up）、旋转（Pivot）等各种分析动作，以求剖析数据，使用户能从多个角度、多侧面地观察数据库中的数据，从而深入理解包含在数据中的信息。
应用OLTP，就必须重新定义OLTP在企业信息化体系结构中的地位。OLTP不再只是一套能处理订单的老式应用程序。对典型的OLTP系统处理的大规模数据流更新进行同时分析，这种情况很罕见，因为一般认为这不是OLTP的目的。
数据仓库更新固有的延迟阻碍着对最新数据的近实时分析。组织如果要对于数据的变化迅速作出反应，IT部门就必须让OLTP产生比以往更大的作用。
参考资料来源：网络-OLTP
参考资料来源：网络-联机分析处理
‘玖’ sql server2014几个不同的版本特点和用途
Microsoft SQL Server 2014已经内置最新的安全、功能更新。微软将在愚人节，即Build2014开发者大会期间开放SQL Server 2014资源下载服务。
Microsoft SQL Server 2014为市场带来了部署到核心数据库中的新内存功能，包括内存 OLTP，它是对市场上大多数综合内存数据库解决方案的现有内存数据仓库和 BI 功能的补充。
SQL Server 2014 还提供新的云功能，以简化 SQL 数据库对云技术的采用并帮助您开创新的混合方案。
主要功能：
1.内存 OLTP：
提供部署到核心 SQL Server 数据库中的内存 OLTP 功能，以显着提高数据库应用程序性能。
内存 OLTP 是随 SQL Server 2014 Engine 一起安装的，而无需执行任何其他操作，您不必重新编写数据库应用程序或更新硬件即可提高内存性能。SQL Server 2014 CTP2 增强功能包括 AlwaysOn 支持、增加的 TSQL 外围应用以及能够将现有对象迁移到内存 OLTP 中。
2.内存可更新的 ColumnStore：
为现有 ColumnStore 的数据仓库工作负载提供更高的压缩率、更丰富的查询支持和可更新性，为您提供甚至更快的加载速度、查询性能、并发性和甚至更低的单位 TB 价格。
3.将内存扩展到 SSD：
通过将 SSD 作为数据库缓冲池扩展，将固态存储无缝且透明地集成到 SQL Server 中，从而提高内存处理能力和减少磁盘 IO
4.增强的高可用性
1) 新 AlwaysOn 功能：可用性组现在支持多达 8 个辅助副本，可以随时读取这些副本，即便发生了网络故障。故障转移群集实例现在支持 Windows 群集共享卷，从而提高了共享存储利用率和故障转移复原能力。
2) 改进了在线数据库操作：包括单个分区在线索引重建和管理表分区切换的锁定优先级，从而降低了维护停机影响。
5.加密备份：在内部部署和 Windows Azure 中提供备份加密支持。
6.IO 资源监管：资源池现在支持为每个卷配置最小和最大 IOPS，从而实现更全面的资源隔离控制。
7.混合方案：
1)智能备份：管理和自动完成将 SQL Server 备份到 Windows Azure 存储（从内部部署和 Windows Azure 中）。
2)添加 Azure 副本向导：轻松将 Windows Azure 中的副本添加到内部部署可用性组中。
3)SQL XI（XStore 集成）：支持 Windows Azure 存储 Blob 上的 SQL Server 数据库文件（从内部部署和 Windows Azure 中）
4)部署向导：轻松将内部部署 SQL Server 数据库部署到 Windows Azure 中。
注:微软2014年3月26日正式宣布，云计算操作系统Windows Azure更名为Microsoft Azure，新品牌自4月3日启用。
‘拾’ 数据仓库的并发能力和OLTP类数据库的区别
在数据仓库场景下，对并发能力的要求：
1.用户的多任务能连接进来，这就是连接池的管理。
2.高效完成多任务并发执行，实际上是多任务并发进来后，如何充分利用集群资源，向用户返回执行结果。对于OLTP类数据库来说，用户的任务（SQL）以短事务居多，所以并发能力会比较高。但是在数仓场景下，批处理、复杂查询非常耗费系统资源，对并发能力的要求是几十，例如POC测试中大部分是用5并发、20并发来测试。
由于DWS/LibrA（注1）的集群的Coordinator Node是多活的、对等的，所以整个系统的并发数随着CN的增加可以不断增长。具体的并发能力受限于实际场景：
•短事务：在平安城市某项目中，在混合负载场景下，测试过5000+并发，可以稳定运行。
•长事务：在某银行复杂批处理场景下，20并发可以稳定运行。后续版本会进一步优化。
独创技术：提供一种基于流水线执行模式的查询内存自适应解决方法，解决多并发场景下系统资源抢占问题，实现无论多大并发，系统稳定运行。