相同sql在不同数据库耗时不同分析    sql查询时间不同，有很多方面影响，上层比如索引、数据量、分区、锁等原因，下层存储、架构等原因，具体事件具体分析，以下只是我遇到的一种情况。操作步骤：1：执行sql2：执行计划对比3：数据总量对比4：表结构对比5：索引对比6：数据行数对比 7：建议

执行sqlselect * from FFXX where FFXXID in (select min(FFXXid) from FFXX where SJZT=1 and FJBJ=3 and fjr=1 and JGSJ>=to_date('2014-11-22 00:00:00','yyyy-mm-dd HH24:Mi:SS') and JGSJ

执行计划对比分析：B库该表分区，条件时间所在分区数据基数非常小，所以直接走全表扫描C库该表不是分区，索引基数非常大，但是走索引是该表最好的方式

数据总量对比select sum(bytes)/1024/1024 from dba_segments where segment_name='FFXX';分析：从中可以看出sql在B库数据库执行该表，数据总范围是32M但是在C库数据库总范围是2628M

表结构对比分析：B库该表创建了分区，C库没有创建分区

索引对比分析：B库时分区索引，C库时普通索引

数据行数对比分析：B库所在分区数据量才8W，C库是749W 

建议将C库数据库中的该表该造成分区表 注释：分区表的好处之一是减少数据查询范围总量

附加数据库就是将一个备份磁盘中的数据库文件(.MDF)和对应的日志文件(.LDF)拷贝到需要的计算机，并将其添加到某个SQL Server数据库服务器中，由该服务器来管理和使用这个数据库。

把需要附加的数据库文件拷贝到自己想存储的目录下，然后单击“数据库”，附加

点击添加，选择路径，单击确定，即可完成附加。在数据库界面就可以看到被附加的数据库了

分离数据库就是将某个数据库(如student_Mis)从SQL Server数据库列表中删除，使其不再被SQL Server管理和使用，但该数据库的文件(.MDF)和对应的日志文件(.LDF)完好无损。分离成功后，我们就可以把该数据库文件(.MDF)和对应的日志文件(.LDF)拷贝到其它磁盘中作为备份保存。（以Transino_ZHBB为例子）

打开属性窗口，在属性窗口中选择选项，然后找到状态，把限制访问改成“SIGN_USER”

单机确定之后，显示如下窗口

单击Transino_ZHBB,选择任务下的子菜单分离

如下图,如果消息栏为空，则选择“就绪”，否则“未就绪”，同时选择删除连接，更新统计信息

1. 打开sql server 软件，如图所示

2. 服务器类型选择数据库引擎，点击服务器名称中的下拉菜单，点击浏览更多，

3. 选择登陆服务器选项卡上的网络服务器，等待几分钟，这时候需要网络搜索

4. 选中所要连接的服务器。这里都是局域网中电脑的名称，只要看一看对方电脑叫什么就行了。

5. 身份验证选择sql server 身份验证

6. 输入用户名和密码

   
   

7. 登陆成功，如图所示
   

（本文内容由百度知道网友呆娃丶2436贡献）

前面说到了直接安装mysql数据库，并没有提及数据库相关的一些基础知识，今天来补补基础。

数据库，顾名思义就是存储数据的仓库，可以简单理解为谷仓。不过这个数据仓是按一定的结构存放程序数据的，目的的避免冗余，当程序需要数据时，会发起查询取回相应的数据。

Web程序中目前最常用的仍然是基于关系模型的数据库，如mysql，Oracle，sqlserver等等，这种数据库也叫做SQL数据库，因为是使用结构化查询语言的。不过，近来也出现了文档数据库和键值对数据库，这两种数据库合称NoSQL数据库，如MongoDB。

SQL数据库：

关系数据库是把数据存储在表中的，表（二维表）模拟程序中的不同实体。表的列是固定的，称为字段（表示实体的数据属性），行是可以变的，称为记录。表中有个特殊的列，称为主键，它的值是表中各行的唯一标识符。表中还可以有外键，所谓外键就是引用同一个表或不同表中某行的主键。这样行之间的联系，就是关系，这就是关系型数据库的基础。关系数据库存储数据高效，而且避免了重复，但是，把数据分别存放在多个表中还是很复杂的，需要各种关联操作。

NoSQL数据库：

所有不遵循关系模型的数据库都可以统称为NoSQL数据库。NoSQL数据库一般使用集合代替表，使用文档代替记录。这样的方式是会使得联结变得困难的。它的特点是减少了表的数量，增加了数据的重复量，缺点是更新某数据会变得耗时，因为要跟新大量文档，优点就是可以没有复杂的关联快速查询。

两类数据库孰优孰劣呢？这个根据存在即合理，都是有各自存在优势与应用场景的，要视具体需求选择具体的数据库。

策划｜Gary

作者｜何恺铎

美国时间 2017 年 10 月 2 日，微软最新一代数据库 SQL Server 2017 正式发布。SQL Server 2017 带来了一系列全新的功能与设计，体现了微软在数据平台建设方面的最新思考和实践。InfoQ 特邀国双科技高级技术总监何恺铎撰文对 SQL Server 2017 进行深入探讨和解析，以飨各位读者。

写在前面

数十年来，关系型数据库一直是结构化数据存储的不二之选。从高校到工业界，关系型数据库向来是数据研究和应用的核心，也促生了大批从事数据库开发、维护和调优的人才。近年来随着各种 NoSQL 数据库和 Hadoop 技术生态的诞生和流行，RDBMS 似乎受到了巨大的挑战，有着“严谨呆板”形象的关系型数据库一度被市场唱衰。然而事实证明，即便面对着众多后起之秀的竞争，有着悠久历史的关系型数据库不但没有消亡，反而历久弥坚，不断推陈出新，在现代后端数据架构中仍然占据核心地位，散发出十足活力。

微软 SQL Server 数据库，是商业关系型数据库阵营中的杰出代表，在 DB-Engines 数据库流行度排行榜上常年位居前三。得益于便捷的图形化管理界面和易于上手的特点，许多人的关系型数据库之旅，就是从 SQL Server 开始的。如今正值 SQL Server 2017 发布之际，我们不妨一起来看看 SQL Server 的前世今生，探究微软数据平台发展之路。

微软 SQL Server 自身的历史具有传奇色彩，最初是由微软、Sybase、Ashton-Tate（开发 dBase 的公司）三家合作，将 Sybase SQL Server 数据库移植到 OS/2 操作系统而诞生的。后来随着 OS/2 的挫败和 Windows NT 操作系统的走强，微软停止了与 Sybase 的合作，开始聚焦于为 Windows 平台独立地开发和维护这个数据库产品，此即 Microsoft SQL Server 的由来。为了避免混淆，Sybase 也将自己的数据库从 Sybase SQL Server 重命名为了 Adaptive Server Enterprise(ASE)，从此 SQL Server 仅指微软旗下关系型数据库了。说起来 Sybase 的数据库产品也一度在金融等行业享有盛誉、颇受欢迎，但如今早已风光不再，于 2010 年被 SAP 收购，令人唏嘘。

与 Sybase 分道扬镳之后的 Microsoft SQL Server，倒是稳扎稳打，一路前行。SQL Server 7.0 和 SQL Server 2000 这两个版本基本完成了在原有 Sybase 代码基础上的大量重写和扩展，正式进入企业级数据库的行列；而 SQL Server 2005 则真正走向了成熟，与 Oracle、IBM DB2 形成了商业数据库的三足鼎立之势。之后 SQL Server 历经 2008、2008 R2、2012、2014、2016 各版本的持续投入和不断进化，直至 2017 年 10 月 2 日正式发布了最新版本 SQL Server 2017，也即本文的主角。

近年回顾

在着手分析 SQL Server 2017 新特性之前，我们不妨先来看看 SQL Server 近些年的着力点，一窥其发展思路。

着力点之一，在于 OLAP。传统关系型数据库一般以行为基本的处理和存储单位，以便于数据记录的增删改查。但面对日益增长的数据分析和聚合类查询，基于行的存储和处理就显得有些笨拙和低效了。为此，在以 Denali 为代号的 SQL Server 2012 中，微软引入了一个全新的 xVelocity 列式存储与分析引擎，使得 SQL Server 拥有了一个高质量的列式存储实现，以及一个为矢量化和批处理高度优化的查询执行引擎。从此面向 OLAP 负载的数据表可以选择建立基于列存储的非聚集索引（Non Clustered Column Store Index），大幅提升了分析类查询性能。在后续的 SQL Server 版本中，列存储相关特性不断得到进一步的增强和完善，不但引入了列存储聚集索引（Clustered Column Store Index）使数据表能够完全仅以列式存储，还通过 Delta-Store 机制实现了列存储表的数据更新支持，进一步拓宽了应用场景，增强了易用性。

笔者还清晰记得多年前在自己的 Thinkpad T410 上首次尝试 SQL Server 2012 的列存储索引时带来的震撼，针对近亿行数据的分析查询在普通笔记本上也做到了数秒内的返回结果，令人印象深刻。历经多年的打磨之后，可以说微软的列存储实现已经成为世界范围内最高效最可靠的列存储设计之一。 相关技术微软甚至还作了一定程度的对外输出：通过与 HortonWorks 合作，微软向开源世界的 Apache Hive 项目贡献了不少代码（被称为 Stinger 项目，[注 1]），帮助 Hive 提速，其思想精髓也正来自于 SQL Server 的 xVelocity 列式存储和分析引擎。

着力点之二，在于 OLTP。传统关系型数据库其实本就擅长 OLTP，那么可改进的点在哪里呢？计算机发展的历史进程所带来的一个问题是，经典的数据库存储机制大都针对磁盘结构进行设计和优化，原本昂贵的内存资源更多充当的是缓存的角色。而随着硬件技术不断发展，服务器内存不断增大后，许多场景下数据的存储和索引其实都可以完全纳入内存中了——这就为基于内存的数据库引擎提供了条件。当一个数据库引擎及其存储完全为内存优化和设计后，其性能的增幅将是非常惊人的。微软数年前在这一领域进行了大举投入，代号为 Hekaton 的内存数据库技术最早在 2012 年底对外进行了公布[注 2]，后随 SQL Server 2014 正式发布。配合其无锁的并发模型及用 SQL 撰写的本机编译存储过程（Natively Compiled Stored Procedure），相比传统方案，Hekaton 往往能够达到多达数十倍的性能提升，完全地改变了许多系统的设计思路，实现了之前难以企及的高负荷场景支撑。

可以看到，截止到 SQL Server 2016 版本，这款微软的拳头产品已经非常强大和完整，能够在单个产品内提供 OLAP 和 OLTP 负载的完美融合。那么仅过了短短一年时间，最新的 SQL Server 2017 还能带来哪些新的惊喜？我们来一看究竟。

新特性之跨平台与容器化

SQL Server 2017 第一个不得不提的变化，不是一个具体功能，而是其运行环境的变革：支持 Linux 服务器。这是微软 SQL Server 系列产品首次正式地得以在 Linux 上运行，并且提供完整的官方支持。这无疑大大拓宽了 SQL Server 的应用场景和客户群体。要知道，虽然 Windows Server 的授权并不算昂贵，但对于许多以 Linux 生态为主要技术栈的公司而言，并不会考虑申购和运维基于 Windows 的后端服务器——因此在技术选型时，SQL Server 可能第一时间就被排除在外了。当 SQL Server 2017 正式支持 Linux 后，这一障碍将不复存在，SQL Server 终于可以在新的战场和竞争对手开展竞争，这无疑会非常有助于其市场份额的提升。

当然，看上去深度耦合于 Windows 的 SQL Server 想要完美地运行于 Linux 上，实现起来绝非一件容易的事情。这是怎样做到的呢？这里有两个关键因素：

其一是 SQL Server 原本就有称为 SQL OS 的底层基础设施，该组件可绕过操作系统和 Win32 API 的限制，直接自行管理和组织 CPU、内存等计算和存储资源，以及进行适合自己的线程调度，以便充分利用底层硬件性能；

其二是来自微软研究院的 DrawBridge 项目，该项目原用于实现应用沙盒机制，它的 Library OS 组件依靠仅约 50 个底层内核调用实现了一千多个常用的 Windows API，同时还具备为其他组件如 MSXML 和 CLR 等提供宿主的能力。

SQL Server 团队基于这两个已有基础进行了伟大的尝试，将二者进行了必要的重写和充分的融合，形成了新一代的底层封装 SQLPAL(SQL Platform Abstraction Layer)，同时将上层逻辑代码都移植到了 SQLPAL 之上——这是 SQL Server 得以在短时间内实现跨平台的关键所在。与此同时，SQLPAL 这种特殊的抽象机制，并没有付出通常意义上抽象所带来的性能代价，因为它一定程度地绕过了操作系统的制约，自底向上地搭建了自身所需的运行环境。

SQL Server on Linux 实现原理[注 3]

前面回顾历史时我们提到，SQL Server 在 90 年代努力地独立与成长，战略性地聚焦在了 Windows 平台。而 20 多年后，SQL Server 如今跨出拥抱 Linux 的关键一步，同样是一种战略的调整。历史看似循环往复，其实都是不同时代不同环境下的最佳商业选择。

为了给 SQL Server on Linux 保驾护航，微软还和 Red Hat 等老牌 Linux 提供商达成了合作[注 4]，一起为客户提供整合解决方案，以确保操作系统层面的可靠性及与 SQL Server 的兼容性。目前 SQL Server 能够被安装到 Red Hat Enterprise Linux、SUSE Linux Enterprise Server 及 Ubuntu 之上。伴随着 Linux 支持一起到来的，还有对于容器的支持。SQL Server 2017 现能完美地通过 Docker 运行，微软也已在 Docker Hub 上发布了基于 SQL Server on Linux 的官方 SQL Server 镜像[注 5]（微软同时还提供了面向 Windows 容器的版本）。SQL Server 容器化的主要意义在于支持 DevOps。在以往，想要让 SQL Server 这样一个重型数据库实例按需地、自动地启动或关闭是比较困难的，一般都需要事先安装准备好相关的数据库环境；而如今，借助容器和镜像，我们可以非常方便地通过 Docker 来轻量化地启停 SQL Server，通过脚本与 DevOps 流程进行集成也变得很容易。

笔者曾经在自己的一个开源类库[注 6]中做过这样的尝试，将原有的依赖于 SQL Server LocalDB 的一系列集成测试迁移到了新的 SQL Server 容器上，顺利解除了本地测试运行环境必须安装 SQL Server 的依赖，也为在远端 CI 环境中运行测试扫清了障碍。当然，除了 DevOps 方面的应用，也可以尝试在生产环境直接使用容器化的 SQL Server，以便使数据库也统一纳入生产环境容器编排的范畴。限于篇幅，此处不再展开。

如上所述，SQL Server 2017 已从原来固守 Windows 的策略，大步地转向了支持 Linux、Docker 容器和 Windows 三大平台。这一决策无疑将对 SQL Server 乃至数据库市场产生深远影响。

新特性之图数据处理

向新兴的 NoSQL 学习也是现代关系型数据库发展的一个重要特征。如文档型数据库善于处理的 JSON 数据，在 SQL Server 2016 中也成为了一等公民，得到了存储、索引、查询等方面的全面支持。而在 SQL Server 2017 中，这位数据库老前辈与时俱进，又开始向 Neo4j 这样的后起之秀学习，大胆地引入了图数据的处理与支持[注 7]。

众所周知，图数据库的核心实体是节点和边，通常都拥有一些属性，然后节点通过边进行相互关联。在传统关系型数据库中，对图进行建模其实并不困难，可以通过为节点和边分别建表并通过外键关联的方式来完整表达图的信息。然而，主要的问题在于查询和查询的性能：一些典型的图查询的表达在传统关系型数据库中显得笨拙而困难，尤其当需要在图的节点间进行多次跳跃（multi-hop）时，SQL 的撰写比较容易出错，查询性能也不能得到保证。

SQL Server 2017 中的图数据库特性试图解决这两个问题，它仍然以表的形式来对图信息进行建模和存储，但加上了额外的扩展，大幅提升了易用性。在创建表时，现可通过 T-SQL 的扩展语法来指定此表是图数据库中的节点表 (AS NODE) 或边表 (AS EDGE)，随后 SQL Server 会隐式地为表加上 $node_id 或是 $edge_id、$from_id、$to_id 等字段，以帮助记录节点和节点间的关系；在查询时，SQL Server 2017 一定程度借鉴了 Neo4j 中 Cypher 查询语言的部分语法，通过引入 MATCH 关键词来帮助用户以 ASCII-art 的方式表达有向图中的节点巡游，同时完美地融合进现有的 SQL 查询体系。我们不妨来看一个官方的查询样例：

可以看到，上述 T-SQL 片段能够很方便地表达出“John 的朋友喜爱的餐馆”这个包含两种不同连接类型的“二跳式”查询，并且用 ACSII 字符表达的箭头也很好地体现了边的方向性。若与相同语义的传统 SQL 写法相比，这样的表达方式无疑清晰、直观得多。

图数据库特性在 SQL Server 2017 中已初露峥嵘。当然，由于此特性是首次引入，客观上来讲并没有到达完全成熟的程度。例如，不支持 transitive closure（节点间不限跳跃次数的连通性判断）和 polymorphism（查询某节点所能到达的不同类型的节点）等图数据库常用的高级查询。在性能方面，SQL Server 目前主要利用的也仅是二维表的既有索引和查询优化器所作的表连接优化，尚没有引入为图优化的专用数据结构。期待后续的版本升级和更新会在这些方向上做进一步的增强。

新特性之数据库内机器学习

机器学习无疑是近年来的热词，也是现代数据应用不可或缺的组成部分。微软虽然在此领域拥有雄厚的研究实力和成果，但在构建相关开发生态上却显得动作缓慢。早年的 SQL Server Analysis Service 虽然也内置了数据挖掘功能，但因过于笨重及程序集成困难等问题，使用场景非常受限。直到近年，微软才开始逐渐发力：在 2015 年初，微软果断地将 Revolution Analytics 收入囊中[注 8]。此次收购至关重要，它为微软带来了面向 R 语言生态的全面的开源和商业解决方案，覆盖了庞大的 R 语言社区和数据科学家人群。

那么作为经典的关系数据库，SQL Server 如何应对和适应这个新趋势呢？受益于 Revolution Analytics 的收购，SQL Server 2016 版本带来了突破性的 SQL Server R Services[注 9]：能够让 R 语言及其生态直接作为一个服务在 SQL Server 环境内部运行。而在 SQL Server 2017 中，更进一步加入了另一个拥有强大 AI 生态的语言支持：Python。原有的 R Services 也与新引入的 Python 服务一起重命名为 Machine Learning Services。

Machine Learning Services 的核心产品思路，是在数据库内直接运行机器学习负载，它允许大家熟悉的 Python/R 脚本与众多机器学习类库在数据库服务器上运行，并无缝地与 SQL 衔接。这样的设计理念，与传统的数据库外独立的机器学习相比有何好处呢？在笔者看来，�...

众享比特近日正式发布基于区块链技术的数据库应用技术平台：ChainSQL。区块链是一种建立在密码学基础上的新型链式数据结构，其数据不可伪造、无法篡改等特性是现有数据库不具备的，可以很好解决困扰传统数据库的安全问题。ChainSQL的诞生，进一步推动了数据库技术的演进。从数据库的长远发展来看，数据库与区块链融合的趋势已无法阻挡。

功能丰富，灵活通用

ChainSQL的设计基于区块链相关技术，将区块链特性与传统数据库相结合，去芜存菁，打造了独特的日志式数据库系统。ChainSQL完美继承了区块链技术不可篡改、可追溯的特性，保障了数据的安全、可审计。对数据库表的操作记录全部记录在了区块链网络中，我们可以知道交易发生的时间、具体内容。审计人员只需要从可靠的区块链网络节点中去恢复一张数据库表即可完成对数据的审计。

ChainSQL支持多种语言API，兼容多种数据库，可以实现数据的插件式管理。常用数据库包括DB2、Firebird、MySQL、ODBC、 PostgreSQL、SQLite3等，均可通过配置如插件般使用，传统数据库接入的成本极低。

（ChainSQL系统架构）

多种应用场景将陆续实现

首先，ChainSQL可作为基础技术平台构建天然容灾多活数据库，多活特性保障了数据库系统的高可用性，部分节点退出不影响系统运行；通过区块链的共识机制实现数据的强一致性，节点间数据保持完美同步。ChainSQL可以灵活方便地加入多活节点，使数据库扩容变得轻松快捷。

在ChainSQL正式发布的同时，众享比特发布了两款基于ChainSQL技术平台的中间件产品：AlAisc（众享多活数据库中间件）、AlBisc（众享数据库灾备中间件）。AlAisc真正实现多个数据中心同时提供服务。数据中心将不再有主备之分，每个数据中心均为生产中心，并互为“备份”。AlBisc将数据操作以交易的方式达成节点共识并存储在区块链上，既可实现数据库的多节点备份，也可通过执行日志操作恢复数据库到任何时间点。该系列产品实现了ChainSQL在不同灾备场景的应用，对数据库灾备要求较高的金融行业将成为首要客户群体。

同时，ChainSQL也可作为快速开发区块链相关应用的基础平台，给开发者带来更便捷的使用体验。任何想用真实数据库来存储数据的应用，同时想兼顾区块链特性的应用，都可以使用ChainSQL，通过调用ChainSQL提供的接口来迅速完成。

众享比特团队发布ChainSQL技术平台标志着“数据库+区块链”的实现。区块链作为近年的技术热点，也将不断刷新传统行业与传统技术的可能性。

　　【IT168 技术】导语：根据DB-Engines的统计，过去三年来，图数据库已成为数据库增长最快的类别。而亚马逊进入图数据库市场将使这种增长加速。更重要的是，这为企业增加了更多的选择机会，与所有市场一样，更多的竞争和选择将带来更大的市场和更好的产品，最终，受益的是用户。

　　现在所有主要的数据库玩家都已经加入图形数据库的行列，市场发展的下一阶段将趋于成熟。虽然一些图形数据库已经存在十年以上（如：Neo4j），但是今天的大部分图数据库产品依然可以说都是全新的。图数据库是否引起了你关注？图数据库又是否适合你的应用程序？

　　什么是图数据库？

　　在研究图数据库之前，我们先定义一些术语。什么是图数据库？图数据库用图来存储数据，是最接近高性能的一种用于存储数据的数据结构方式之一。

　　构成一张图的基本元素是节点（点）和关系（线）。节点和关系都可以设置自己的属性。节点经常被用于表示一些实体，但依赖关系也一样可以表示实体。节点之间的关系是图数据库很重要的一部分。通过关系可以找到很多关联的数据，比如节点集合，关系集合以及他们的属性集合。

　　相对于关系数据库中的各种关联表，图形数据库中的关系可以通过关系能够包含属性这一功能来提供更为丰富的关系展现方式。

　　灵活性是推动图数据库流行度激增的关键因素。在过去10年的时间里，对可用性和大规模的相同需求推动了各种NoSQL产品的开发和采用，从图数据库近期的趋势中看，这种走势将继续走强。

　　何时需要图数据库？

　　与任何流行的技术一样，有人可能会将图数据库应用于任何类型的问题上。但了解图数据库擅长的应用领域依然是非常重要的。例如，图数据库通常应用于问题域有：

　　＊ 社交网络；

　　＊ 推荐和个性化；

　　＊ 客户360，包括实体解析（关联多个来源的用户数据）；

　　＊ 欺诈识别；

　　＊ 资产管理；

　　以上的各个应用领域或许与你的应用程序并不匹配，你也可以从以下因素中确定图数据库是否适合你的应用程序：

　　＊ 多对多的关系。Martin Kleppmann在《设计数据密集型应用程序》（O'Reilly）一书中提到，如果问题中频繁的出现多对多关系，建议使用图表，因为关系数据库往往难以有效地处理这些关系。

　　＊ 高价值的关系。经常听到的另一个观点：如果数据元素之间的关系与元素本身一样重要，甚至比元素本身更重要时，则应考虑使用图表。

　　＊ 大规模的低延迟。在应用程序中添加另一个数据库也会增加应用程序的复杂性，图数据库能够比其他类型的数据库更快地处理大型数据集所表示的关系。尤其是在复杂的关系连接查询不再执行，并且没有对查询或关系结构进行额外优化的情况下。

　　使用Gremlin定义图表模式和查询

　　让我们从一个真实的例子来开始了解图数据库。KillrVideo是一个参考应用程序，用于共享和观看为帮助开发人员学习使用DataStax Enterprise而制作的视频，其中包括DataStax Enterprise Graph —— 基于高度可扩展的数据技术（包括Apache Cassandra和Apache Spark）的图数据库。

　　使用Gremlin语言在DataStax Enterprise Graph中描述和交互图表，也是Apache TinkerPop项目的一部分。由于Gremlin的灵活性、可扩展性以及对声明式和命令式查询的支持，被称为描述图遍历的首选语言。Gremlin是基于Groovy语言的。最重要的是，Gremlin得到了DataStax Enterprise Grap等大多数流行图数据库的支持，包括DataStax Enterprise Graph、Neo4j、AWS Neptune和Azure Cosmos DB在内。

　　我们设计了一个推荐算法来识别作为需要输入的数据。该方法类似于给特定户推荐喜爱的视频。我们的目标是在用户与KillrVideo应用程序交互时（即作为OLTP交互）实时生成推荐。

　　为了定义模式，我们确定了由KillrVideo管理的数据的一个子集，这是图所需要的。包括用户、视频、评分和标签，以及可能在算法中引用的这些项目的属性，或者在推荐结果中提供的属性。然后我们在Gremlin中创建了一个如下所示的图表模式：

　　选择将用户、视频和标签建模为顶点，并使用线来确定哪些用户上传了哪些视频，用户给视频的评分以及与每个视频关联的标签。我们将属性分配给在查询中引用或包含在结果中的顶点和线上。DataStax Studio是一种用于在CQL和Gremlin中开发和执行查询的笔记本式开发工具。

　　基于这个模式，我们定义了将数据填充到图中的查询，以及从图中检索数据的查询。以下是生成推荐的图表查询基本流程：确定特定的用户、识别与特定用户喜欢同一类视频的类似用户、选择类似用户喜欢的视频、排除特定用户已经观看过的视频、按照受欢迎程度对这些视频进行排序，并生成结果。

　　到目前为止，在这个遍历中我们已经确定了类似用户。遍历的第二部分采用了类似的用户抓取他们喜欢的一定量的视频，去除特定用户已经观看过的视频，并生成按受欢迎程度排序的结果集。

　　虽然这个遍历看起来很复杂，但这是推荐算法的整个业务逻辑，在这里我们就不详细的介绍这个遍历过程中的每一步了。

　　我们建议使用DataStax Studio或Apache TinkerPop的Gremlin控制台等工具，在代表性数据集上交互式地开发遍历。这使你可以快速迭代并优化遍历。DataStax Studio是一个基于Web的环境，提供了多种方法来将遍历结果可视化为节点和边的网络，如下图所示。

　　将图数据库合并到架构中

　　一旦你设计了图表模式和查询，就可以将图表集成到你的应用程序中。以下是我们将DataStax Enterprise Graph集成到KillrVideo中的方法。 KillrVideo的多层架构由一个Web应用程序组成，该应用程序位于一组管理用户、视频（包括标签）和评级的微服务之上。这些服务利用DataStax Enterprise Graph数据库（基于Apache Cassandra）进行数据存储，并使用CQL访问数据。

　　我们将推荐引擎作为推荐视频服务的一部分实施，如下所示。此服务将生成一个特定用户标识的建议列表。为了实现推荐引擎，我们将上述的Gremlin遍历翻转换为Java代码。

　　这种架构突出了微服务体系结构中的一个常见挑战 —— 需要与多个服务拥有的数据进行交互。如上所示，用于生成推荐的图表依赖于用户管理、视频目录和评分服务的数据。

　　我们通过使用异步消息来保存现有服务的数据所有权。用户管理、视频目录和评分服务在数据更改上发布事件。推荐的视频服务订阅这些事件，并对这些图表进行相应的更新。

　　在Java中实现Gremlin遍历

　　DataStax Java驱动程序提供了一个友好又流畅的API来实现Gremlin与DataStax Enterprise Graph的遍历。API能轻易使在DataStax Studio中创建的基于Groovy的查询转换为Java代码。

　　然后，我们可以通过使用名为DSLs的Gremlin特性（即域名特定语言）来使Java代码更具可读性和可维护性。DSL是Gremlin进入特定领域的延伸。对于KillrVideo，我们创建了一个DSL来扩展与视频域相关的术语的Gremlin遍历实现。KillrVideoTraversalDsl类定义查询操作，例如user（）（它使用提供的UUID定位图中的顶点）和recommendByUserRating（），它根据参数（例如最低等级和请求推荐量）为用户生成推荐。

　　使用DSL将推荐视频服务的实现简化为如下的示例，它创建了一个GraphStatement，然后我们使用DataStax Java Driver执行：

　　使用DSL，可以在可重用函数中隐藏图表交互的一些复杂性，然后根据需要将它们组合起来形成更复杂的遍历。这将允许我们额外的推荐引擎，从user（）方法提供的特定用户顶点开始，允许应用程序在不同的实现之间进行交换。

　　希望通过这篇文章你能了解一些关于图数据库对你的应用程序的意义，以及如何使用Gremlin和DataStax Enterprise Graph。

MySQL作为甲骨文一个非常优秀的开源免费数据库，而SQL server作为微软一个付费的优秀数据库，难免有时候，我们需要将MySQL数据库迁移到SQL SERVER数据库，今天我就带着大家一起来完成这个任务。

工具介绍

SSMA是一个客户端应用程序，从上面我们能够看到，这个工具不仅仅有MySQL版本的，还有DB2、oracle、Access等等数据库的，也就是说，利用这些工具，我们能够将各种数据库迁移到SQL SERVER，同时，支持的SQL SERVER版本有2008、2008 R2、2012、2014、2016、2017版本和Azure SQL Database版本等。

系统要求

目前关于MySQL版本的这个迁移工具需要满足以下系统需求：

Windows 7或者之后的版本；或者Windows server 2008或者之后的版本

推荐使用4GB RAM

框架需要4.0之后的版本

需要MySQL ODBC 5.1驱动程序

其他需求

为了迁移系统函数、存储过程等等，你需要安装Extension Pack

实现步骤

当我们安装好上面的两个迁移工具之后，我们可以参考以下的步骤来实现真正的迁移数据库操作：

用这个工具连接MySQL数据库

连接SQL SERVER实例

转变MySQL数据库对象到SQL SERVER（比如数据表、索引、存储函数、存储过程等等）

加载对象（数据表、索引、存储函数、存储过程等等）进入到SQL SERVER

迁移数据到SQL server

总结

从上面的描述，我们不难看出，从MySQL迁移到SQL SERVER数据库，需要同时安装MySQL数据库和SQL SERVER数据库，并且为了链接MySQL，我们还需要安装MySQL的ODBC，这样才能够让这个工具正常与MySQL进行通信，以保证迁移的顺利进行。

一、附加数据库与分离数据库相反，只有分离的数据库才能附加，分离后的数据库不能再正常读取，只有附加后才能读取；而还原数据库是指在原有数据库的基础上进行，一般选择覆盖原有数据库，SQL中如果不存在这个库是不能还原的（物理设备上要有库文件）。客户的服务器需要重装，小编是先备份原库（使用软件或SQL备份或停止SQL直接拷走数据库文件或在PE下拷走），重装完成后拷回原位置直接附加（个人经验附加始终比还原快），使用还原的情况比较少。还原数据库小编之前已经分享过，这里不再赘述。今天小编来分享下数据库的分离与附加。

二、分离数据库

1、选中要分离的库—右键“所有任务”—分离数据库

2、如果存在数据库连接可“清除”，点击“确定”

3、分离成功

三、附加数据库

1、要在“数据库”上右键—所有任务—附加数据库

2、附加数据库界面：点击按钮

3、选择要附加的数据库文件，注意要选择.MDF的文件，.LDF是日志文件

4、选择好后的界面，注意“指定数据库所有者”，有的是sa，有的是其它的，比如科脉是km

5、点击“确定”，附加成功

四、有时候轻度数据库置疑也可以通过“分离—附加”来修复，不过还是不建议这样做。我是百家号作者小白信息说，专注电子信息领域经验分享、技术交流，感谢关注！

前几天同和君被某粉丝吐槽不务正业，那今天咱们就来务一下正业，来简单讲讲有关SQL Server的基础操作（其实是为了交差）。

有关SQL（结构化查询语言）与其对应的各类数据库管理系统（SQL Server、Access等）的功能与运用范围，在这里就不做赘述了，有兴趣的可以去搜一下，然后你就会发现一个新的世界了~

首先下载安装SQL Server并配置其实例，这方面也不详细说明了，有点电脑基础的都会~然后就是正式的实操环节，首先连接到服务器：

进入后第一件事当然是创建属于自己的数据库啦~

右键「数据库」，选择新建，然后跳出右边的对话框，根据实际需求来设置「文件初始大小」、「文件增长量」、「日志初始大小」、「日志增长量」。

增长方式和文件大小上线可以自定义。

确定后就能看的建立好的数据库了。

试着生成一个有关数据库信息的脚本~

详细sql文件信息如下：

当然你也可以选择使用Transact-SQL语言直接来创建数据库：

先点「新建查询」调出查询分析编译器：

然后输入以下语句：

createdatabase HKSDBonprimary(name=HKSDB_data,filename='d:\File\TEMP\HKSDB_data.mdf',size=20MB,maxsize=500MB,filegrowth=5MB)log on(name=HKSDB_log,filename='d:\File\TEMP\HKSDB_log.mdf',size=20MB,maxsize=100MB,filegrowth=1MB)

右键相应的数据库属性会跳出很多选项：

如果你把数据库的初始值设高了，可以通过收缩来减小：

接着是通过代码来查看&修改数据库属性：

--查看数据库属性sp_dboption HKSDB--查看数据库信息sp_helpdb HKSDB--修改日志文件的最大值和初始值use HKSDBgoalterdatabase HKSDB modifyfile(name=HKSDB_log,maxsize=200MB)alterdatabase HKSDB modifyfile(name=HKSDB_log,size=40MB)--更改数据库use HKSDBalterdatabase HKSDBaddfile(name=HKSDBFZ,filename='D:\File\TEMP\HKSDBFZ.ndf',size=2mb,maxsize=10mb,filegrowth=1mb)alterdatabase HKSDBadd log file(name=HKSDBLOG1,filename='D:\File\TEMP\HKSDBLOG1.ldf',size=2mb,maxsize=10mb,filegrowth=1mb)use HKSDBalterdatabase HKSDBremove file SYDBFZalterdatabase HKSDBremove file HKSDBLOG1如果你对某个数据库不爽，想把它打入冷宫，可以直接右键数据库删除，也可以手动输入代码：

use HKSDBdropdatabase HKSDB似乎碰上了钉子户：

试试大神的代码：

USE MASTER GO DECLARE@dbname SYSNAME SET@dbname='同和君的的数据库'--这个是要删除的数据库库名 DECLARE@s NVARCHAR(1000)DECLARE tb CURSORLOCALFORSELECT s ='kill '+ CAST(spid ASVARCHAR)FROM MASTER..sysprocesses WHERE dbid = DB_ID(@dbname)OPEN tb FETCHNEXTFROM tb INTO@sWHILE @@fetch_status=0BEGINEXEC(@s)FETCHNEXTFROM tb INTO@sENDCLOSE tb DEALLOCATE tb EXEC('drop database ['+@dbname+']')

完美~

好的，那么到这里大家已经大致了解了数据库的定义与管理，接下来带大家起飞了~

手动一个个创建数据表是一件很苦逼的事情，再加上我们还没学到JAVA和SQL Server链接的JDBC技术，所以同和君选择一种取巧的方式：从Excel表格直接导入数据~

选好数据源类型：

选好目标文件后下一步：

然后对目标表的各项数据分别选好类型（其中大多都系统默认好了，局部地区稍微修改下就好，比如学号之类的）：

我们来预览一下~

成功~

然后我们可以开始骚操作了~

不过在此之前，还是先教大家如何备份&还原吧~

接下来是还原，这回我们导入一个不同的~

这个是我用来做多表连接的~详细的后边会讲到~

首先我们来查一下同和君初恋女孩高一的成绩：

然后保存该sql文件：

然后再查一下初中好基友的总分区排名：

再保存下：

然后查一下b站up主@SmartMogician 的黑历史

哟，竟然出现同校同学同名同姓的情况了！

这样的话就能成功筛选了：

没想到当年的语文竟然这么难！

当年的学霸……

这样看可能更直观：

（emmmm……这真的不是招生办的阴谋……）

这样看上去就舒心多了~

很多朋友应该都存在偏科的现象，但在我们的深入研究下，发现事情并不简单：

语文不好的同学不一定数学好，

但数学不好的同学就有可能语文好了……

三倍的人数差还是能说明问题的……

那么以上呢，就给大家详细展示了大多常用查询指令的用法~接下来给大家介绍的是「连接查询」，通过这个就能实现多表之间的查询了。

成绩与排名两个表连接，分析理科总成绩与数学成绩之间的关系：

看样子综合能力好的同学，真的是每一门都不偏科呢！

最后同和君要做一件集大成的骚操作~

首先合并一下数据：

嘿嘿嘿~

我们来看看初中的那些朋友们到了高中后学习状态如何~

唯一能对应上的只有姓名了，结果如下：

换个表试试：

大数据显示，初中成绩好的高中成绩不一定好，但高中成绩好的初中成绩一定不差！

什么？有人想看我的成绩？

抱歉，这两个表里都没有我的名字hhh，成绩好就是可以为所欲srgsrgz

[数据删除]

大家也看到了，现在在某二本混日子的我……(；д；)

所以学习这玩意嘛……哎，不谈了不谈了……

接下来介绍一些增删查改的相关操作：

--增加一条记录insert N校联考 (考号,姓名,班级,学校)values('10001','同和君','一班','社会大学')--求表中各校总分的平均分，并存入一个新的数据库createtable AvgMarks(学校 nvarchar(255),平均分 real)insertinto AvgMarks(学校,平均分)select 学校,AVG([9科总分分数])from N校联考groupby 学校--将「N校联考」中所有「广州市第五中学」的信息更新为「广州五中」update N校联考set 学校='广州五中'where 学校='广州市第五中学'执行结果：

ok，那么就暂且先告一段落吧，基本操作讲完了，下回咱们就讲讲高级操作吧~

鸣谢以上十七所高校提供的成绩信息~