13518219792
？？是要基本代码吗？？SQL(Structured query language,结构化查询语言)
创新互联建站主营万荣网站建设的网络公司,主营网站建设方案,app软件定制开发,万荣h5成都小程序开发搭建,万荣网站营销推广欢迎万荣等地区企业咨询
建表：create table 表名(字段名 类型 大小)
主键设置：not null primary key
修改表的三大操作：
删除：alter table 表名 drop 字段名
增加：alter table 表名 add 字段名 数据类型
修改：alter table 表名 alter 字段名 数据类型 --此命令只能修改字段类型，无法修改名称
修改数据的三大操作：
添加记录：insert into 表名 【（字段名）】values (数据)
【】为缺省，可以选择不输入
修改数据：update 表名 set 字段名=表达式 【where 条件】
删除数据：delete 字段名列表 from 表名 【where条件】
其余命令：
删除整张表命令：drop table 表名
联合查询：(select ……) unino (select ……)
子查询：select * from (select ……) as 1,(select …… ) as 2
数据查询命令：
select 字段表达式/*/all/distinct(翻译：去掉重复项)/top(选择显示部分，可以是明确数字或者百分比) from 数据源 where/group by(按照某一字段分组) ……【having】(此处是分组的同时设置条件)/order by (排序，两个值，Asc 是升序，DEsc是降序)
SOA与微服务的区别？
SOA的提出是在企业计算领域，就是要将紧耦合的系统，划分为面向业务的，粗粒度，松耦合，无状态的服务。服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构下的系统。
基于这些基础的服务，可以将业务过程用类似BPEL流程的方式编排起来，而BPEL反映的是业务处理的过程，这些过程对于业务人员更为直观，调整也比hardcode的代码更容易。
当然企业还需要对服务治理，比如服务注册库，监控管理等。
我们知道企业计算领域，如果不是交易系统的话，并发量都不是很大的，所以大多数情况下，一台服务器就容纳将许许多多的服务，这些服务采用统一的基础设施，可能都运行在一个应用服务器的进程中。虽然说是面向服务了，但还是单一的系统。
而微服务架构大体是从互联网企业兴起的，由于大规模用户，对分布式系统的要求很高，如果像企业计算那样的系统，伸缩就需要多个容纳续续多多的服务的系统实例，前面通过负载均衡使得多个系统成为一个集群。但这是很不方便的，互联网企业迭代的周期很短，一周可能发布一个版本，甚至可能每天一个版本，而不同的子系统的发布周期是不一样的。而且，不同的子系统也不像原来企业计算那样采用集中式的存储，使用昂贵的Oracle存储整个系统的数据，二是使用MongoDB，HBase，Cassandra等NOSQL数据库和Redis，memcache等分布式缓存。那么就倾向采用以子系统为分割，不同的子系统采用自己的架构，那么各个服务运行自己的Web容器中，当需要增加计算能力的时候，只需要增加这个子系统或服务的实例就好了，当升级的时候，可以不影响别的子系统。这种组织方式大体上就被称作微服务架构。
微服务与SOA相比，更强调分布式系统的特性，比如横向伸缩性，服务发现，负载均衡，故障转移，高可用。互联网开发对服务治理提出了更多的要求，比如多版本，比如灰度升级，比如服务降级，比如分布式跟踪，这些都是在SOA实践中重视不够的。
Docker容器技术的出现，为微服务提供了更便利的条件，比如更小的部署单元，每个服务可以通过类似Node.js或Spring Boot的技术跑在自己的进程中。可能在几十台计算机中运行成千上万个Docker容器，每个容器都运行着服务的一个实例。随时可以增加某个服务的实例数，或者某个实例崩溃后，在其他的计算机上再创建该服务的新的实例。
如何拆分服务？
要围绕业务模块进行拆分，拆分粒度应该保证微服务具有业务的独立性与完整性，尽可能少的存在服务依赖，链式调用。但是，在实际开发过程中，有的时候单体架构更加适合当前的项目。实际上，微服务的设计并不是一蹴而就的，它是一个设计与反馈过程。因此，我们在设计之初可以将服务的粒度设计的大一些，并考虑其可扩展性，随着业务的发展，进行动态地拆分也是一个不错的选择。
REST的名称"表现层状态转化"中，省略了主语。"表现层"其实指的是"资源"（Resources）的"表现层"。
所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。
客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。
实际上呢，不是所有的东西都是“资源”，尤其是在业务系统中，缺点如下：
有个接口是更新订单状态，你是用上面的GET POST PUT DELETE 哪个呢，看样子应该是PUT，但是路径呢PUT /tickets/12
我有时候多个接口 ，更新订单收款状态，更新订单支款状态，更新订单结算状态；
Restful 的路径明显不友好不够用；
再比如，批量删除，DELETE还好用么，DELETE /tickets/12 #删除ticekt 12 这种形式如果要传数组怎么办，url是不是不够友好？
再比如，Resuful要求 GET /tickets # 获取ticket列表 。我们曾经有个需求，对方会把不超过1000个订单id传给我们，我们系统过滤其中一部分特殊订单；这也是个查询服务，用GET /tickets # 获取ticket列表的形式，1000个订单id显然是超过GET url长度的，这里也不合适；再者，我想开发多个条件查询列表服务，路径这么浅显然不合适；
实际业务中，我们webapi的路径是这样的：systemAlias/controller/action
总结下规则：
简单查询尽量用GET，好处是可以直接带查询参数copy api路径；
复杂查询和更新用POST，用的最多；
不用PUT和DELETE，原因是增加复杂度，并没有带来什么好处
看看BAT的很多openapi，也是写着restful，实际没有严格遵守，都是get和post，这是也很多人不知道put和delete的原因
如：
//根据订单id获取订单
GET oms/order/queryOrderById?id=value1param2=value2
//根据订单id List获取订单
POST oms/order/queryOrderByIdList
//根据条件查询订单，带分页参数
POST oms/order/queryOrderByCondition
//更新订单收款状态
POST oms/order/updateOrderCollectionStatus
//批量更新订单收款状态
POST oms/order/updateOrderCollectionStatusInBatch
//批量更新订单收款状态
POST oms/order/updateOrderCollectionStatusInBatch
//批量删除订单，带操作来源
POST oms/order/deleteOrderInBatch
微服务如何进行数据库管理？
CAP 原理(CAP Theorem)
在足球比赛里，一个球员在一场比赛中进三个球，称之为帽子戏法(Hat-trick)。在分布式数据系统中，也有一个帽子原理(CAP Theorem)，不过此帽子非彼帽子。CAP 原理中，有三个要素：
CAP 原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求 ，否则就失去了价值，因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。
对于大多数 WEB 应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。
当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。
牺牲一致性，只是不再要求关系型数 据库中的强一致性，而是只要系统能达到最终一致性即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。
通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则 取决于数据复制到一致状态的时间。
最终一致性(eventually consistent)
对于一致性，可以分为从客户端和服务端两个不同的视角。
从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。
从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。
一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。
从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。
对于关系型数据库，要求更新过的数据能被后续的 访问都能看到，这是强一致性 ;如果能容忍后续的部分或者全部访问不到，则是弱一致性 ; 如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。
从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。
那么问题来了，如何实现数据的最终一致性呢?答案就在事件驱动架构。
最佳解决办法是采用事件驱动架构。其中碰到的一个挑战是如何原子性的更新状态和发布事件。有几种方法可以解决此问题，包括将数据库视为消息队列和事件源等。
从目前技术应用范围和成熟度看，推荐使用第一种方式(本地事务发布事件)，来实现事件投递原子化，即可靠事件投递。
SpringCloud和Dubbo有哪些区别？
总体来说，两者各有优势。虽说后者服务调用的功能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的依赖，这在强调快速演化的微服务环境下，显得更加合适。
品牌机与组装机的区别：很明显SpringCloud比dubbo的功能更强大，覆盖面更广，而且能够与SpringFramework、SpringBoot、SpringData、SpringBatch等其他Spring项目完美融合，这些对于微服务至关重要。使用Dubbo构建的微服务架构就像组装电脑、各环节我们选择自由度高，但是最总可能会因为内存质量而影响整体，但对于高手这也就不是问题。而SpringCloud就像品牌机，在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性。
在面临微服务基础框架选型时Dubbo与SpringCloud只能二选一。
一般数据仓库面试会面两轮，第一轮一般是sql技术面，第二轮就是 维度建模 和 数据治理 的问题。
一轮技术面（待补充）：
1、数据倾斜：
数据倾斜一般产生的原因是数据在map端hash分配到reduce端时，某一个key的数量远大于其他的key，导致某一个reduce的处理时间较长。
1）key分布不均匀
2）数据本身就是如此
3）数据关联时没有把握好关联键
解决方案
1）参数调整：hive.map.aggr = true;hive.groupby.skewindata=true;
当存在数据倾斜时开启负载均衡，此时会生成两个MapReduce任务，第一个MR任务会将map端产生的key随机的分配到reduce，先进行一次聚合，第二个MR任务会将第一个任务的预处理结果作为输入，将相同的key分配到同一个reduce当中。
2）sql调整：在处理大量空值导致数据倾斜的情况下，可以先将空值附一个特殊值去处理，比如给一个随机数加字符串的方式，因为空值数据是关联不上的，不会影响后期处理。
2、order by，sort by，cluster by，distribute by的区别
1）order by是全局排序，排序过程在一个reduce中进行，在数据量较大时就会很慢
2）sort by是局部排序，排序结果在同一个reduce中使有序的
3）distribute by是将数据按照字段划分到一个reduce中，一般与sort by连用进行分组排序的作用
4）cluster by除具有distribute by功能外还具有sort by的功能
order by优化（阿里面试）：
1）开启严格模式，order by之后添加limit子句
2）利用sort by，在每个reduce中先排序取出top项，再把预处理结果order by输出
3、hive中内部表和外部表的区别
1）在创建表的时候，内部表是将数据移动到数据仓库指向的路径，外部表仅记录数据所在的路径，不对数据的位置做任何改变。
2）在删除表的时候，内部表会将元数据和数据都删除，外部表只删除元数据。
4、列转行、行转列
1）列转行：lateral view explode(split('column_name',','))作为一个新表
2）行转列：concat_ws(',',collect_set(column_name))
5、mapreduce运行原理
6、数据仓库分层原理（阿里面试）
7、维度建模中三种事实表的应用场景（阿里面试）
二轮面试（待补充）
如下这些有关数据库知识考查的经典笔试题，非常全面，对计算机专业毕业生参加笔试会很有帮助，建议大家收藏。
一、选择题
1. 下面叙述正确的是___c___。
A、算法的执行效率与数据的存储结构无关
B、算法的空间复杂度是指算法程序中指令(或语句)的条数
C、算法的有穷性是指算法必须能在执行有限个步骤之后终止
D、以上三种描述都不对
2. 以下数据结构中不属于线性数据结构的是___c___。
A、队列B、线性表C、二叉树D、栈
3. 在一棵二叉树上第5层的结点数最多是__b____。2的(5-1)次方
A、8 B、16 C、32 D、15
4. 下面描述中，符合结构化程序设计风格的是___a___。
A、使用顺序、选择和重复(循环)三种基本控制结构表示程序的控制逻辑
B、模块只有一个入口，可以有多个出口
C、注重提高程序的执行效率 D、不使用goto语句
5. 下面概念中，不属于面向对象方法的是___d___。
A、对象 B、继承 C、类 D、过程调用
6. 在结构化方法中，用数据流程图(DFD)作为描述工具的软件开发阶段是___b___。
A、可行性分析 B、需求分析 C、详细设计 D、程序编码
7. 在软件开发中，下面任务不属于设计阶段的是__d____。
A、数据结构设计 B、给出系统模块结构 C、定义模块算法 D、定义需求并建立系统模型
8. 数据库系统的核心是___b___。
A、数据模型 B、数据库管理系统 C、软件工具 D、数据库
9. 下列叙述中正确的是__c____。
A、数据库是一个独立的系统，不需要操作系统的支持
B、数据库设计是指设计数据库管理系统
C、数据库技术的根本目标是要解决数据共享的问题
D、数据库系统中，数据的物理结构必须与逻辑结构一致
10. 下列模式中，能够给出数据库物理存储结构与物理存取方法的是___a___。
A、内模式 B、外模式 C、概念模式 D、逻辑模式
11. Visual FoxPro数据库文件是___d___。
A、存放用户数据的文件 B、管理数据库对象的系统文件
C、存放用户数据和系统的文件 D、前三种说法都对
12. SQL语句中修改表结构的命令是___c___。
A、MODIFY TABLE B、MODIFY STRUCTURE
C、ALTER TABLE D、ALTER STRUCTURE
13. 如果要创建一个数据组分组报表，第一个分组表达式是"部门"，第二个分组表达式是"性别"，第三个分组表达式是"基本工资"，当前索引的索引表达式应当是__b____。
A、部门+性别+基本工资 B、部门+性别+STR(基本工资)
C、STR(基本工资)+性别+部门 D、性别+部门+STR(基本工资)
14. 把一个项目编译成一个应用程序时，下面的叙述正确的是___a___。
A、所有的项目文件将组合为一个单一的应用程序文件
B、所有项目的包含文件将组合为一个单一的应用程序文件
C、所有项目排除的文件将组合为一个单一的应用程序文件
D、由用户选定的项目文件将组合为一个单一的应用程序文件
15. 数据库DB、数据库系统DBS、数据库管理系统DBMS三者之间的关系是_a___。
A、DBS包括DB和DBMS B、DBMS包括DB和DBS
C、DB包括DBS和DBMS D、DBS就是DB，也就是DBMS
16. 在"选项"对话框的"文件位置"选项卡中可以设置___b___。
A、表单的默认大小 B、默认目录
C、日期和时间的显示格式 D、程序代码的颜色
17. 要控制两个表中数据的完整性和一致性可以设置"参照完整性"，要求这两个表_a_。
A、是同一个数据库中的两个表 B、不同数据库中的两个表
C、两个自由表 D、一个是数据库表另一个是自由表
18. 定位第一条记录上的命令是___a___。
A、GO TOP B、GO BOTTOM C、GO 6 D、SKIP
19. 在关系模型中，实现"关系中不允许出现相同的元组"的约束是通过__b____。
A、候选键 B、主键 C、外键 D、超键
20. 设当前数据库有10条记录(记录未进行任何索引)，在下列三种情况下，当前记录号为1时;EOF()为真时;BOF()为真时，命令?RECN()的结果分别是___a___。
A、1,11,1 B、1,10,1 C、1,11,0 D、1,10,0
21. 下列表达式中结果不是日期型的是___c___。
A、CTOD("2000/10/01") B、{^99/10/01}+365
C、VAL("2000/10/01") D、DATE()
22. 只有满足联接条件的记录才包含在查询结果中，这种联接为___c___。
A、左联接 B、右联接 C、内部联接 D、完全联接
23. 索引字段值不唯一，应该选择的索引类型为___b___。
A、主索引 B、普通索引 C、候选索引 D、唯一索引
24. 执行SELECT 0选择工作区的结果是___b___。
A、选择了0号工作区 B、选择了空闲的最小号工作区
C、关闭选择的工作区 D、选择已打开的工作区
25. 从数据库中删除表的命令是___a___。
A、DROP TABLE B、ALTER TABLE C、DELETE TABLE D、USE
26. DELETE FROM S WHERE 年龄60语句的功能是__b____。
A、从S表中彻底删除年龄大于60岁的记录
B、S表中年龄大于60岁的记录被加上删除标记
C、删除S表 D、删除S表的年龄列 1 2
a)select pname as '商品名',avg(qty) as 平均销售量 from s,p,m where m.city='上海' and s.mno=m.mno and p.pno=s.pno，select p.Pno,p.pname,sum(s.qty)
from s left join p on s.pno=p.pno left join m on p.Mno=m.Mno
where m.city='上海市'
group by p.Pno,p.pname,p.city,p.color
b)、先删除Sale表的外键PNO，再删除gds表。
c)联系：视图（view）是在基本表之上建立的表，它的结构（即所定义的列）和内容（即所有数据行）都来自基本表，它依据基本表存在而存在。一个视图可以对应一个基本表，也可以对应多个基本表。视图是基本表的抽象和在逻辑意义上建立的新关系
区别：1、视图是已经编译好的sql语句。而表不是
2、视图没有实际的物理记录。而表有。
3、表是内容，视图是窗口
4、表只用物理空间而视图不占用物理空间，视图只是逻辑概念的存在，表可以及时四对它进行修改，但视图只能有创建的语句来修改
5、表是内模式，视图是外模式
6、视图是查看数据表的一种方法，可以查询数据表中某些字段构成的数据，只是一些SQL语句的集合。从安全的角度说，视图可以不给用户接触数据表，从而不知道表结构。
7、表属于全局模式中的表，是实表；视图属于局部模式的表，是虚表。
8、视图的建立和删除只影响视图本身，不影响对应的基本表。
NoSQL太火，冒出太多产品了，保守估计也成百上千了。
互联网公司常用的基本集中在以下几种，每种只举一个比较常见或者应用比较成功的例子吧。
1. In-Memory KV Store : Redis
in memory key-value store，同时提供了更加丰富的数据结构和运算的能力，成功用法是替代memcached，通过checkpoint和commit log提供了快速的宕机恢复，同时支持replication提供读可扩展和高可用。
2. Disk-Based KV Store: Leveldb
真正基于磁盘的key-value storage, 模型单一简单，数据量不受限于内存大小，数据落盘高可靠，Google的几位大神出品的精品，LSM模型天然写优化，顺序写盘的方式对于新硬件ssd再适合不过了，不足是仅提供了一个库，需要自己封装server端。
3. Document Store: Mongodb
分布式nosql，具备了区别mysql的最大亮点：可扩展性。mongodb 最新引人的莫过于提供了sql接口，是目前nosql里最像mysql的，只是没有ACID的特性，发展很快，支持了索引等特性，上手容易，对于数据量远超内存限制的场景来说，还需要慎重。
4. Column Table Store: HBase
这个富二代似乎不用赘述了，最大的优势是开源，对于普通的scan和基于行的get等基本查询，性能完全不是问题，只是只提供裸的api,易用性上是短板，可扩展性方面是最强的，其次坐上了Hadoop的快车，社区发展很快，各种基于其上的开源产品不少，来解决诸如join、聚集运算等复杂查询。
