select m.订单编号，m.订单总额 , d.商品名称 , d.商品单价
创新互联是一家集网站建设,梅河口企业网站建设,梅河口品牌网站建设,网站定制,梅河口网站建设报价,网络营销,网络优化,梅河口网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。
from order_t m,order_good_t d
where m.订单编号 = d.订单编号
扩展资料:
SQL中最常见的操作（查询）使用声明性SELECT语句。 SELECT从一个或多个表或表达式中检索数据。标准SELECT语句对数据库没有持久影响。 SELECT的一些非标准实现可以具有持久性效果，例如某些数据库中提供的SELECT INTO语法。
WHERE子句包含比较谓词，它限制查询返回的行。 WHERE子句从结果集中删除比较谓词未计算为True的所有行。
GROUP BY子句将具有公共值的行投影到较小的行集中。 GROUP BY通常与SQL聚合函数结合使用，或者从结果集中消除重复的行。 WHERE子句在GROUP BY子句之前应用。
参考资料来源：百度百科-SQL语法
一、分库分表的必要性
分库分表技术的使用，主要是数据库产生了瓶颈，如单库的并发访问或单表的查询都超出了阈值。对系统使用造成一定的影响，不得已而产生的技术。
通过分库分表技术来解决此类问题，但正因为使用此技术，会产生ACID一系列的问题，各类中间件解决此类问题各有各的优势。
提示：如场景无必要，千万不要使用分库分表。
二、分库分表的思路
1、垂直区分
垂直分库：从业务角度，一个库分成多个库，如把订单和用户信息分成两个库来存储。这样的好处就是可以微服务了。每块的业务单独部署，互不影响，通过接口去调用。
垂直分表：把大表分成多个小表，如热点数据和非热点数据分开，提高查询速度。
2、水平区分
水平分表：同一业务如数据量大了以后，根据一定的规则分为不同的表进行存储。
水平分库：如订单分成多个库存储，分解服务器压力。
以上一般来说，垂直分库和水平分表用的会多些。
三、分库分表的原理分析
分库分表常用的方案：Hash取模方案和range范围方案；
路由算法为最主要的算法，指得是把路由的Key按照指定的算法进行存放；
1、Hash取模方案
根据取余分配到不同的表里。要根据实际情况确认模的大小。此方案由于平均分配，不存在热点问题，但数据迁移很复杂。
2、Range范围方案
range根据范围进行划分，如日期，大小。此方案不存在数据迁移，但存在热点问题。
四、分库分表的技术选型
1、技术选型
解决方案主要分为4种：MySQL的分区技术、NoSql、NewSQL、MySQL的分库分表。
（1）mysql分区技术：把一张表存放在不同存储文件。由于无法负载，使用较少。
（2）NoSQL（如MongoDB）：如是订单等比较重要数据，强关联关系，需约束一致性，不太适应。
（3）NewSql(具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID和SQL等特性):如TiDB可满足需求。
（4）MySQL的分库分表：如使用mysql,此种方案为主流方式。
2、中间件
解决此类问题的中间件主要为：Proxy模式、Client模式。
（1）Proxy模式
（2）Client模式
把分库分表相关逻辑存放在客户端，一版客户端的应用会引用一个jar，然后再jar中处理SQL组合、数据库路由、执行结果合并等相关功能。
（3）中间件的比较
由于Client模式少了一层，运维方便，相对来说容易些。
五、分库分表的实践
根据容量（当前容量和增长量）评估分库或分表个数 - 选key（均匀）- 分表规则（hash或range等）- 执行（一般双写）- 扩容问题（尽量减少数据的移动）。
在这里我们选用中间件share-jdbc。
1、引入maven依赖
2、spring boot规则配置
行表达式标识符可以使用${...}或$-{...}，但前者与Spring本身的属性文件占位符冲突，因此在Spring环境中使用行表达式标识符建议使用$-{...}。
3、创建DataSource
通过ShardingDataSourceFactory工厂和规则配置对象获取ShardingDataSource，ShardingDataSource实现自JDBC的标准接口DataSource。然后即可通过DataSource选择使用原生JDBC开发，或者使用JPA, MyBatis等ORM工具。
很复杂！！
在 EXPLICIT 模式中，查询书写器控制由执行查询所返回的 XML 文档的形式。必须以特定的方式编写查询，将有关预期嵌套的附加信息显式指定为查询的一部分。可用 directive 在列级指定附加的配置。当指定 EXPLICIT 模式时，必须负责确保生成的 XML 符合语法规则并且有效（对于 XML-DATA 架构）。
EXPLICIT 模式将查询执行所得到的行集转换为 XML 文档。为使 EXPLICIT 模式生成 XML 文档，行集必须具有特定的格式。这需要以某种方式编写 SELECT 查询以生成具有特定格式的行集（称为通用表），可对该行集进行处理以生成请求的 XML 文档。
Customer CustomerID="ALFKI"
Order OrderID=10643
Order OrderID=10692
...
/Customer
Customer CustomerID="ANATR"
Order OrderID=10308
Order OrderID=10625
...
/Customer
成所得到的 XML 树的查询生成通用表，该表包含两个元数据列：Tag 和 Parent。因此，在指定查询时 SELECT 子句必须指定这两列。这两列中的值用于生成 XML 层次结构。
Customer 元素位于顶层。在下面的示例中，指派给此元素的 Tag 值为 1（该值可以是任何数字，但是有唯一的数字与每个元素名相关联）。因为 Customer 是顶层元素，所以其 Parent 标记值为 NULL。
Order 元素是 Customer 元素的子元素。因此，Order 元素的 Parent 标记值为 1（将 Customer 标识为其父元素）。指派给 Order 元素的 Tag 值为 2。
可使用两个 SELECT 语句编写查询并使用 UNION ALL 组合这两个语句的结果：
在第一个 SELECT 语句中，获取所有 Customer 元素及其特性值。在含有多个 SELECT 语句的查询中，只使用在第一个查询中指定的列名（通用表列名）。忽略在第二个 SELECT 语句中指定的列名。因此，指定 XML 元素和特性名的通用表的列名包含在下面的查询中：
SELECT 1 as Tag,
NULL as Parent,
Customers.CustomerID as [Customer!1!CustomerID],
NULL as [Order!2!OrderID]
FROM Customers
在第二个查询中检索所有 Order 元素及其特性值：
SELECT 2,
1,
Customers.CustomerID,
Orders.OrderID
FROM Customers, Orders
WHERE Customers.CustomerID = Orders.CustomerID
使用 UNION ALL 组合此查询中的两个 SELECT 语句。
以只进方式对通用表行集（包含所有数据和元数据）逐行扫描，以生成所得到的 XML 树。为了输出正确的 XML 文档层次结构，指定通用表中的行顺序也很重要。为此可在查询中使用 ORDER BY 子句。
下面是最终查询：
SELECT 1 as Tag,
NULL as Parent,
Customers.CustomerID as [Customer!1!CustomerID],
NULL as [Order!2!OrderID]
FROM Customers
UNION ALL
SELECT 2,
1,
Customers.CustomerID,
Orders.OrderID
FROM Customers, Orders
WHERE Customers.CustomerID = Orders.CustomerID
ORDER BY [Customer!1!CustomerID], [Order!2!OrderID]
FOR XML EXPLICIT
所得到的通用表是有四列的表。为了举例说明，只显示几行。
Tag Parent Customer!1!CustomerID Order!2!OrderID
1 NULL ALFKI NULL
2 1 ALFKI 10643
2 1 ALFKI 10692
2 1 ALFKI 10702
2 1 ALFKI 11011
2 1 ALFKI ...
1 NULL ANATR NULL
2 1 ANATR 10308
2 1 ANATR 10625
2 1 ANATR ...
下面描述处理通用表中的行以生成所得到的 XML 树：
第一行标识 Tag 值 1。标识所有含有 Tag 值 1 的列。只有一列含有 Tag 值 1：Customer!1!CustomerID。此列名由元素名 (Customer)、标记号 (1) 和特性名 (CustomerID) 组成。因此，创建 Customer 元素并向其添加特性 CustomerID。然后将该列值指派为该特性值。
第二行有 Tag 值 2。因此，标识所有含有 Tag 值 2 的列。只有一列含有 Tag 值 2：Order!2!OrderID。此列名由元素名 (Order)、标记号 (2) 和特性名 (OrderID) 组成。该行也将 Customer 标识为其父元素（Parent 值为 1）。结果，创建 Order 元素作为 Customer 元素的子元素并向其添加特性 OrderID。然后将该列值指派为该特性值。
以相同的方式处理后面含有 Tag 值 2 的所有行。
标识含有 Tag 值 1 的某行。标识含有 Tag 值 1 的 Customer!1!CustomerID 列。该列标识没有父元素（Parent 为 NULL）的 Customer 元素。因而，关闭前面的 Order 标记和 Customer 标记。打开新的 Customer 标记并重复此过程。
因为没有在查询中指定 Directive，所以特性名是 XML 特性的名称。下面是部分结果集：
Customer CustomerID="ALFKI"
Order OrderID="10643" /
Order OrderID="10692" /
Order OrderID="10702" /
Order OrderID="11011" /
/Customer
Customer CustomerID="ANATR"
Order OrderID="10308" /
Order OrderID="10625" /
/Customer
简单说。你要
1.使用 EXPLICIT 模式
2.你要知道 XML 层次结构
3.你要看得懂通用表中的行以生成所得到的 XML 树
条件：SQL必须是完整版的，sql2000 可以
开始——程序——microsoft SQL sever——查询分析器——选择正确的数据库——输入语句——f5
NewSQL是对一类现代关系型数据库的统称，这类数据库对于一般的OLTP读写请求提供可横向扩展的性能，同时支持事务的ACID保证。这些系统既拥有NoSQL数据库的扩展性，又保持传统数据库的事务特性。NewSQL重新将“应用程序逻辑与数据操作逻辑应该分离”的理念带回到现代数据库的世界，这也验证了历史的发展总是呈现出螺旋上升的形式。
在21世纪00年代中，出现了许多数据仓库系统 (如 Vertica，Greeplum 和AsterData)，这些以处理OLAP 请求为设计目标的系统并不在本文定义的NewSQL范围内。OLAP 数据库更关注针对海量数据的大型、复杂、只读的查询，查询时间可能持续秒级、分钟级甚至更长。
NoSQL的拥趸普遍认为阻碍传统数据库横向扩容、提高可用性的原因在于ACID保证和关系模型，因此NoSQL运动的核心就是放弃事务强一致性以及关系模型，拥抱最终一致性和其它数据模型 (如 key/value，graphs 和Documents)。
两个最著名的NoSQL数据库就是Google的BigTable和Amazon的Dynamo，由于二者都未开源，其它组织就开始推出类似的开源替代项目，包括Facebook的 Cassandra (基于BigTable和Dynamo)、PowerSet的 Hbase(基于BigTable)。有一些创业公司也加入到这场NoSQL运动中，它们不一定是受BigTable和Dynamo的启发，但都响应了NoSQL的哲学，其中最出名的就是MongoDB。
在21世纪00年代末，市面上已经有许多供用户选择的分布式数据库产品。使用NoSQL的优势在于应用开发者可以更关注应用逻辑本身，而非数据库的扩展性问题；但与此同时许多应用，如金融系统、订单处理系统，由于无法放弃事务的一致性要求被拒之门外。
一些组织，如Google，已经发现他们的许多工程师将过多的精力放在处理数据一致性上，这既暴露了数据库的抽象、又提高了代码的复杂度，这时候要么选择回到传统DBMS时代，用更高的机器配置纵向扩容，要么选择回到中间件时代，开发支持分布式事务的中间件。这两种方案成本都很高，于是NewSQL运动开始酝酿。
NewSQL数据库设计针对的读写事务有以下特点：
1、耗时短。
2、使用索引查询，涉及少量数据。
3、重复度高，通常使用相同的查询语句和不同的查询参考。
也有一些学者认为NewSQL系统是特指实现上使用Lock-free并发控制技术和share-nothing架构的数据库。所有我们认为是NewSQL的数据库系统确实都有这样的特点。
