但伴随着业务的变化，当离线做到没什么可以继续做的时候，实时就会被拿出来，作为新一个阶段的目标进行攻克。
在流批一体建设之前，这种实时诉求通常会开发成分钟级的任务，通过近实时的方案来解决业务的问题，但分钟级会带来诸如任务过多、资源挤占较大、无法支持复杂逻辑等问题。
因此专门支持实时计算的框架，比如早期的Storm，能够尝试从纯实时的角度解决业务问题，就被拿出来作为尝试。然而Storm的局限性也很大，因为那会的任务开发只能通过Java的方式来进行，与Hive所推崇的纯SQL方案相比，上手难度大了不少，同时两套代码的逻辑几乎没有可比性，这种方案也就一直没有什么声音。
尽管实时技术有各种缺陷，但作为一种能够很容易讲清楚价值的项目，同时又非常便于向上汇报的技术方案，实时技术还是被或多或少的做了起来。在大多数的公司里，实时和离线就会有不同的团队进行维护，或者是同一个团队，但分成不同的项目来执行。这个阶段，优先高效的把业务做起来，哪怕场景再简单，但能够证明实时有价值和前景，这个阶段的目标就算完成了。
以上的各种方案，难免会带来三个特别难以解决的问题：
（1）数据的口径上，实时和离线很容易不统一；
（2）数据模型的规范上，实时和离线也往往是分开建设；
（3）即便是同一种口径和同一种规范，实时和离线也要分成两套代码来维护。
这三个问题短时间内会被高速发展掩盖掉，但当业务对实时的诉求越来越多、压力越来越大的时候，口径和代码的不统一，就会越来越成为阻碍敏捷开发的障碍，需要有方案进行解决。
后来Flink出现了，带来了流批一体的全新方案，这个问题便出现了解决的曙光，这也比较接近我们对于实时计算的理想方案，因为其意义堪比Hive，也成为了各个大厂面试的标配问题。
然而，仅仅学会Flink是不够的，因为流批一体带来的并不仅仅是技术方案或者是框架的改变，同样带来了数据模型的改变，这就要求我们从数据模型上，而不是技术方案上，来制定我们的实时方案。
那么我们如何理解“实时数据模型”这件事情呢？
通常而言，我们关心的内容，包括如下几个方面：
（1）实时数据源与离线数据源存在差异，导致相同的字段，取值或者类型会存在不相等的情况；
（2）实时和离线由于底层执行机制的不同，通常需要维护两套代码，会带来诸如口径不统一、质量检测难的问题；
（3）产品逻辑变化较快时，离线模型修改相对容易，但实时模型需要考虑压测、削峰、重启等技术问题，维护成本非常高昂。
数据仓库之所以能够普及并被业务接受，正是因为其模型能够屏蔽掉底层差异的问题，并且有相对可靠的数据质量监控方法，并且变更成本非常低。而实时数仓如果想要替代掉离线数仓，以上的问题通常是需要一些模型设计甚至是平台工具的来解决，这些问题解决的重要性，并不比Flink弱。
我们先从比较可控的模型层面说起。
在离线的概念里，数仓模型设计成了DWD/DWS/ADS三个层级，原本的概念是DWD面向事实表的构建，DWS面向公共指标的统一，ADS负责灵活的口径变化问题。
在离线的概念里，DWD/DWS/ADS三个层级需要保留，但负责的目标会有一些变化，同时还需要增加存储统一层，也就是以TiDB/Holo为代表的数据库，来承担服务分析一体化的诉求。
让我们先看DWD层，DWD承担了屏蔽实时离线链路差异的问题，最重要的作用是保证表结构的统一及字段内容的对齐。DWD最重要的意义，是保证离线表和实时表，其表结构和字段概念是相同的。
为什么这么强调？试想一下，在离线场景下，我们可以在DWD上灵活的增加各种统计标签，或者是将维度退化到事实表，都是一些left join或者是服务端直接打标可以解决的事情。但在实时场景下，这会变成多流join或者是缓存等更复杂的技术场景，导致这些信息并不能有效的记录到DWD，因此DWD的设计就要产生一些变化，有一些内容在实时场景下无法准确记录，这一类信息需要标识到对应的字段描述上，下游使用时才不会出错。
同时，实时和离线存储数据的介质，也必然有一些区别。例如离线可以存在HDFS上，实时则可能视情况保存在数据库、HDFS甚至是内存中，这时候对于字段格式、读取方式都会有差异，设计表时其约束条件也会更多。
因而，DWD更多承担了逻辑统一的职责，依旧以事实表为基础，但约束条款要比离线更多。
再看一下DWS层，离线上DWS是负责口径统一的重要一环，将通用的维度和口径计算方法抽象出现，以提供跨数据域的灵活使用。但在实时场景下，这一类的维护收益通常都比较低，不仅因为实时只看当天的数据，也是因为实时本身的维度难度就较大，多一层模型其收益会急速下降，因而大多数时候会忽略掉DWS的建设，ADS直接引用DWD进行统计。
然而，DWS毕竟存储的内容要比DWD少很多，因此如果计算资源瓶颈非常明显，或者是业务场景不需要分析实时明细数据的情况下，或者是DWD的下游引用过多时，DWS可以承担削峰的重任，通过减少数据量以应对大促等场景，还是有一定意义的。
接下来就是最重要的ADS层，在这一层上，逻辑统一、口径统一、大促削峰在前置模型上都得到了一定程度的解决，ADS则像离线一样承担了应对需求变化的重任。
但ADS所面临的情况和离线还是有所不同的，因为ADS的任务启动，不仅要启动一个离线的跑批任务，还要同时启动一个实时的流式任务，而ADS往往会同时统计离线+实时的结果，以应对同比、环比等场景。
这时候很多具体Case要具体分析了，因为特定场景的坑会非常多。例如最常见的“同比”，要对比今年和去年的结果变化，离线往往会统计分小时的结果，但实时会累计起始时刻到当期时刻的结果，因而当一个小时没有结束的时候，这个同比的波动变化会非常大，给人一种“数据是错误的”印象，新手很容易踩这个坑，从而被业务质疑。
因此，针对累计统计指标，从代码设计上就要考虑到这种情况，都根据时间字段统计起始到当前时刻的结果的，在代码逻辑上会要求一些统计技巧。
很多时候，因为业务指标变化太快，改实时代码是来不及的，这时候一部分的工作量甚至需要报表工具的数据集来解决，改动查询sql，要比改动任务来的快捷多了。但这部分的能力，其实是依赖于存储工具的，个人认为可以分到存储统一层来解决。
最后是存储统一层，因为一些特殊的场景，比如实时分析明细数据，或者是不确定时间周期的多天统计结果，如果依赖Flink SQL来解决是有些不现实的，因而这部分的压力需要数据库来承担。
简单讲，就是将明细做轻度的汇总后，直接写到数据库，实时更新，下游自定义条件，并直接读库统计结果。这种场景既要求数据库有OLAP的计算能力，也要有OLTP的稳定特点，因而TiDB和Holo这一类HTAP的引擎就变得非常重要。
因为多了实时的部分，因此过去面向离线的开发工具，也需要有一些特定的改造，以适应实时的开发和运维诉求。
对于开发工具而言，其目标集中在四个场景上：元数据定义与获取、数据建模、开发与测试、运维与监控。
其次讲数据建模，因为建模的理论已经稳定了有些年头了，绝大多数场景下都是按照既定的方案来执行。过去离线当道时，规范执行的弱一些不是什么大问题，但流批一体当道的年代，规范是需要强约束的，这就对了开发工具提出了一定的要求，是否能够从平台层面上对规范进行内置，并以此来约束开发的同学，降低不规范模型对后期维护带来的压力。
这种建模能力的代表有两种，一种是规范表的命名，填写相应的分层+主题域+数据域+统计刷新方式，从源头上规范表的目标和作用；一种是规范指标的定义和使用，例如原子指标还是派生指标，统计周期多少，业务限定用语如何规范，统计粒度怎么填写。
在实际开发中，通过工具的限制，如果规范可以做的好，代码是可以自动生成出来的。当然，以上的功能，都属于通过牺牲开发效率，来提升数据质量的范畴，使用时需要根据团队的情况来限定。
再次是开发和测试，这是平台提供的最重要的能力。在开发层面，就是代码的预编译能力+发布功能。预编译不仅要检查代码的逻辑是否正确，同时对于代码中依赖的其他数据源，获取到的元数据信息是否准确，至少字段的命名不会有大的问题。当代码预编译通过，发布上线后，还需要检测当前是否有资源支持任务启动，并且上游的消息队列是否是启动的状态。
实时的测试一直都是比较大的问题，它不像离线可以启动一个SQL任务看看结果，实时在每个阶段的输入和输出，是需要通过平台支持的日志打印功能来进行辅助的。很多时候我们会新建一个测试专用的topic来测试结果，但对于流量较大的线上任务而言，这种方式无法像离线区分Dev环境一样，能够对资源进行隔离，因而如果能够支持圈定数据的输入和打印输出，对于测试的效率而言无疑是最佳的。
最后要提到的是运维与监控能力。运维能力是指根据输入的RPS，或者是cu使用情况，或者是任务的整体延迟，提供相应的参数调优能力，通过参数来调整任务的执行情况。并且能够根据以上指标的变化，自定义相应的阈值，提供相应的告警能力，通过短信或者是消息工具的方式触达任务维护者。
实时与离线有一些不同的是，离线可以通过增加一个监控节点的方式，通过group by判断数据是否重复，而实时任务则非常依赖Flink自身的一致性能力，因而发现和解决问题的成本更高。
其实做到运维这个环节，对人的要求其实是更高的。因为流批一体在运维上会带来一个好处，即实时任务和离线任务能够错峰执行，实时在白天压力大，而离线在晚上压力大。但同样的，这种方式对于维护者而言更加痛苦，因为不仅晚上要熬夜值班，白天同样不能休息，在大促期间甚至需要轮班来维护任务，可以说是“汇报一时爽，痛苦长相伴”。
从远处来看，流任务和批任务，在自身的机制上就存在非常大的差异，批程序面上的是特定时间内相对静态的数据，而流程序处理的则是change-log，虽然有可能数据在表结构层面，通过数据模型的设计来保持一致，但是在语义层面，其根本还是不一样的。这一点可能是最制约批流一体发展的问题，也是最难实现统一或者永远也不可能统一的。
综上，对于实时模型，开发工具需要将监控实时部分的能力进行补全，就像DWD层需要分别维护实时和离线两套架构一样，开发工具也需要分别维护两套架构的结果，因而现阶段的实时开发，还做不到降低维护和开发的成本，只能减轻其中部分环节的工作量。
以上讲了很长时间的实时模型，但从实际的效果上看，业务并不会感知到多么明显的技术变化，相反会有一种“面子工程”的感觉在里面。
当然，我并不否认实时的价值，在“搜广推”这三个技术占主导的领域内，作用还是很大的。但实时毕竟要比离线的内容，更加的难以理解，出现问题的排查成本也更高。这种复杂性使得我们在应对变化时，往往做不出有效的应对，就会变得特别被动。
因而，说一句事后的话，就是“实时的价值取决于业务方，而不是技术方”。只有业务对实时痛点强烈的场景下，我们做如此复杂的研究和应对，才能体现出自己的价值，更多的时候，是在“王婆卖瓜，自卖自夸”。有这种投入，还不如多招几个分析师更靠谱和实在。
本人之前的文章《天下数据，唯快不破》，重点强调了一个“快”字。但“天下熙熙皆为利来，天下攘攘皆为利往”，这个快更多的是在讲应对“变化”的快，而不是“技术”自己的快。
所以，为了以后的职业发展，我们要跟进实时技术的变化，但从自身的工作角度出发，如何应对业务的变化，才是自己要关心的课题。不能吧，oracle触发器是它自己的数据库对象，如果要向其他数据库写数据，总要有个方法或者标准，告诉oracle如何写，怎么写，向JDBC一样；你可以用自己跑批写，oracle是数据库，不是集成交互工具
肯定是需要维护的，而且要根据网站的运营情况和公司的实际需求进行维护和优化。网站数据库的维护工作的内容如下:
确定网站程序、数据库类型
日常备份
*** 作维护备份
*** 作修改过程
一、网站基础维护
1、内容更新2、修改3、简单Flash修改4、简单Js效果
二、网站安全维护
1、病毒的防治
三、网站数据库维护
1、数据库备份2、数据库导入导出3、数据库的迁移4、数据库数据的恢复和还原5、数据库后台维护
四、故障恢复
1、数据库数据丢失找回
2、网站程序恢复
五、基础优化
1、进行w3c标准优化
一、确定网站程序类型和数据库类型，并取得一下信息
1、取得FTP账号信息，2、如果是大型数据库（例如sqlserver和mysql等），要取得数据库账号信息3、
域名管理信息
二、原始备份在取得网站信息后要对网站进行原始备份，包括数据库数据和网站程序，以下为备份过程：
i以汉语拼音或者英文的第一个字母为文件夹名称，对网站进行分类，便于查找
ii每个文件夹内再建立2-3个文件夹，分别存放，网站原始备份，修改备份，数据库文件以及备份（如果是aess数据库可以和程序放在同一个文件夹内，备份文件以文件名加日期命名）
三、网站修改
1、每次修改从ftp下载最新的文件进行修改，上传之前,需要在ftp备份原文件，以文件名加日期来命名，例如（indexasp命名为indexasp1022）,并及时更新原始备份
2、如果是从网站后台直接拷贝的代码模板进行修改，需要将原模板代码备份到本地文件夹，再将修改好的代码上传。
四、定期备份
1、程序文件每月一号进行一次备份，可采用覆盖原始备份的方式进行备份，如果有重要更新，随时进行一次单独备份，同时保留旧备份，数量为2
2、数据库文件
1）aess数据库可以通过手动的方式每周五备份一次，如果客户要求可以备份。备份保留数量为5份
2)大型数据库，例如sqlserver和mysql，每周五通过服务器控制面板备份，客户要求可以备份。并在本地电脑上通过数据导入导出每15天备份一次，不需要保留旧数据。
3）如果是独享主机可以通过软件在服务器是自动差异备份，设定时间为每周五备份。并在本地电脑上通过数据导入导出每15天备份一次，不需要保留旧数据。
4）若进行数据库结构修改 *** 作，需要对数据库进行完全备份。
网络数据库的重要性
数据库作为应用系统基础的组成部分，其重要性不言而喻。数据库一旦崩溃，将会给企业带来巨大的压力，面临的业务需求与挑战。随着IT技术的发展，企业的应用系统越来越复杂，数据库作为应用系统基础的组成部分，其重要性不言而喻。对于企业而言，一旦数据库崩溃或者数据库的性能降低，那么会直接导致依赖于数据库的应用系统运行速度缓慢或者根本无法使用，其最终结果不仅仅是会影响应用系统的使用效率，甚至会造成企业客户和利润的流失。更有甚者，对于某些企业来说，其日常的运营完全依赖于业务系统，那么一旦业务系统所使用的数据库崩溃，那么会对企业造成根本性的伤害，或者会影响到企业的正常运营。我们为客户带来什么提高管理员的工作效率，改善企业的数据库使用环境
数据库在使用中所出现的问题，可能由表空间、文件系统、数据文件、进程等组件当中的任意一个造成，甚至有可能是由于某一个SQL语句的性能太差造成。因此，当数据库出现问题，彻查问题的根本原因成为重复、繁杂的劳动，MochaBSM将管理员从重复劳动中脱离出来，以主动管理的方式，为管理员提供自动化的监控管理，一旦数据库出现问题，可以马上通知相关的管理员。提前识别可能伤害数据库性能的事件，并采取预防性措施，减少应用停用为企业带来的伤害系统提供了70多个重要的性能指标，一旦性能出现问题，立刻产生相应的事件和报警，并可通过短信、语音等形式主动将事件和报警推送给管理员，让管理员能够实时了解当前的系统运行数据与运行状况，及时解决数据库所存在的问题，防止问题进一步的严重。
监控颗粒度细化，为管理员提供更详尽的信息，便于管理员有依据的优化数据库性能除了监控数据库、表空间、数据文件等组件，系统还可以深入到SQL语句的监控，提供SQL语句排名，可检测性能欠佳的SQL语句，让管理员能够有依据、有针对性的优化数据库的性能，简化管理员的维护工作。
数据库可视化监控，一目了然，降低技术门槛
除了提供详尽、实时的数据，系统还可提供给使用者可视化的监控方式，使用者不必具有专业的数据库知识，也可以了解到数据库的当前状况。
保障业务不间断和连续性，降低运行风险
通过对数据库可用性和性能的监控，保证数据库的健康运行，确保依赖于数据库的业务系统的正常运
行，减少系统的停用时间。
关键功能与亮点
支持主流的数据库，包括
·MSSQLServer2000、2005
·OracleDB9i、10g
·MySQL
·DB2
自动发现被监控的数据库，并且可自动发现数据库上的数据库表和表空间，然后进行监控。
对以下关键组件进行针对性的监控
·数据库
从CPU、内存、连接、锁、事务等方面来监控数据库的性能。
·表空间
数据文件
进程
*** 作系统的文件系统
除了数据展现，更提供可视化的监控方式，可以对文件系统运行情况进行查看和检索。
提供数据库配置的监控，当数据库的配置发生变更，例如数据库内存配置方面的变更等，以不同的颜
色标记配置变更记录，并且系统可第一时间通知管理员所发生的变更。
监控粒度更加细化，提供对于SQL语句的排序，可查看性能较差的SQL语句，为管理员优化数据库提供依据，能够预防更严重问题的发生。
关于数据库的运行数据，系统提供了丰富的报表、报告，并可导出各种文件形式，应用于其他文档。
应用可视化管理，可直观的展现给用户数据库监控的各种数据，让用户对于应用运行的情况有更清晰、直接的感受。
整合ITM、Smarts等第三方软件，便于用户通过一个Portal，了解到全局的信息。
提供宕机的根本原因分析，帮助管理员更快解决问题，使最终用户得到更高品质的应用服务。
一旦系统发生故障，系统生成事件，通过短信，邮件和语音等方式通知关键管理人员。
保护敏感信息和数据资产大多数企业、组织以及政府部门的电子数据都保存在各种数据库中。他们用这些数据库保存一些个人资料,比如员工薪水、医疗记录、员工个人资料等等。数据库服务器还掌握着敏感的金融数据,包括交易记录、商业事务和帐号数据、战略上的或者专业的信息,比如专利和工程数据,甚至市场计划等等应该保护起来防止竞争者和其他非法者获取的资料。数据库服务器还保存着一些有关员工详细资料的东西比如银行帐号、xyk号码,以及一些商业伙伴的资料。
查询输入:(1)分别对单条件进行精确查询
(2)输入长度的检验，输入允许的最长值进行查询，是否支持
(3)两个查询条件是否为2选1，来回选择是否出现页面错误
(4)输入字符
(5)输入特殊字符
(6)输入数字
(7)输入汉字
(8)输入关系表达式与、或、异或、非、等于
(9)输入空格
(10)条件中含有空格
(11)输入超长字符
(12)输入全角字符
(13)输入单引号
(14)输入单引号引起来的数据
(15)输入双引号
(16)输入双引号引起来的数据
(17)如果支持模糊查询，输入部分查询条件
(18)输入系统中不存在与之匹配的条件
查询结果检查
(1)查询结果按什么顺利排序
(2)查询结果是否根据字段显示排序功能
(3)查询结果是否有分页，如果有，每页最多包含多少记录
(4)查询结果是否匹配
(5)查询结果是否与数据库一致
(6)查询结果是精确查询还是模糊查询
UI验证
(1)文字显示是否正确
(2)页面是否有错别字
(3)输入框大小、文字大小是否合适
(4)页面是否美观
(5)查询结果字段显示是否与需求一致
性能方面
(1)查询处理时间是否能接受
(2)数据库中存在大数据量数据时，查询时间是否能接受
(3)当多个用户同时查询时，输入相同或不同的查询条件系统响应是否及时
数据库快照，就是比如你有一个数据库A，你给这个数据库做了一个快照，那么以后你都可以把这个数据库通过换个快照，还原到当时做这个快照时的数据库状态，而不用管这个数据库A有任何的增删改，都能恢复到原始的状态。
类似于我们照相机拍照的功能
1、自己在windows和linux上安装了mysql，自学linux的基础知识，学习mysql的最基础的知识，即怎么写sql，存储过程，表的设计等，从0到熟悉大概花了3个月，推荐《mysql入门很简单》。
2、系统地较为深入地学习mysql的sql优化，备份和恢复，参数优化，架构优化，硬件层面的优化，高可用方案，复制技术等等，这段时间你不一定能实际接触到这些，就像我当初那样，肯定没什么公司招一个小白。
我选择自己看书，推荐《高性能mysql》，里面所有的章节都需要看一遍，以现在的水平肯定看不懂，但需要知道大概怎么回事，为后续的找mysql初级dba的工作打一个铺垫，这个过程大概也需要3个月。
3、纸上得来终觉浅，完成以上两步，我开始准备找一份mysql相关的工作，而不是天天用着excel表格做着selectfromtable_sb这样的工作。
当然我这么猥琐的人肯定不会裸辞，该画的电路板也一样画，业余时间开始投初级mysqldba的工作，并且不间断地学习，网上各种找mysql面试的相关题目（实际上我当时完全没有任何实战经验），陆续收到一些面试，凭借之前自学的mysql知识，开始胡乱吹牛逼，先混进去再说。
你不做mysql实际相关的工作，永远也不知道自己之前认知的db知识有多幼稚。
友情提示一点，一般公司都没有专职dba的，所以面试的时候一定要自信，其实你学了这么多，虽然毫无实战经验，理论知识很大概率比面试你的人牛逼，所以各种吹，我就这样真正进入初级dba的圈子（由于这时对linux还处于cdls的水平，所以之前也根本没做过运维），这个边工作边找工作的过程又持续了2个月。
4、真正进入互联网，接触生产环境后，这是我进步最大的时候。
第一步需要将之前所学真正地应用起来，并且应用的过程中，再回头看之前的书籍，这时候需要真正去理解，而不是似是而非，一知半解。
这时再推荐《高性能mysql第三版》，全本再看一遍，这时需要全部看懂，另外还有《mysql技术内幕：innodb存储引擎》等等。
总之这段时间就需要开始关注mysql一些细节了，比如db故障处理，高可用，负载均衡等等的具体实现了。
另外，linux的知识同步也要深入去学习，至少会写shell脚本，常见的linux知识等，我在这花了1年多；
5、dba的工作一般是非常轻闲的，毕竟不是大公司，技术能力有限，该学的也学得差不多了，接触不到海量数据，高并发等比较锻炼人的场合，于是我又准备跳了。
于是来了公有云，现在每天运维万多个db实例，平均每天处理5个紧急db故障，几乎mysql会遇到的问题，感觉都遇到了，能感觉到技术实力和经验也在每天都在积累，在进步。
但是感觉还是欠缺了很多，下一步就看你选择了，是再去研究源代码，底层原理的东西多点，还是数据库运维和应用多一点，就比如业界姜承尧，何登成与叶金荣的区别。
由于我的历史原因，对c等几乎不懂，平时也用不到，所以看代码等事实际太累，于是我再去学mongodb，接了公司mongodb运维的活，算是在广度上的一个扩展，万一哪天mysql不行了呢
6、总之，对于db小白来说，最重要的一点就是，学习的过程不能断。
PS上面的方法比较野路子，适合没什么基础的童鞋，如果本来就是DBA，比如从oracle转到mysql，那么建议直接看mysql官方文档，而官方文档是db达到一定水平后必看，出问题时必查的权威文档。
怎样用excel做简单的数据库建议到 点击“外部数据”页，选择“EXCEL”
在d出的获取外部数据向导中点击”浏览“
在d出来的浏览窗口找到EXCEL表格所存放的位置选中后点击”打开“
如无特殊数据或要求保留标题直接在后边点击完成，否则点击“下一步”根据提示修改需要的数据类型、保存标题等 *** 作。完成后在左边可以看到数据表名，双击可以正常在ACCESS进行正常 *** 作。
每列的第一行为字段名，根据需要每列可以设置不同的单元格格式（相当于数据类型），每一行为一条记录，这就是一个简单的数据库不。
做个EXCEL表格，比如C3=A1+B2，然后直接往下拉
1、首先，创建空白数据库，在数据库中创建表并插入数据，如下图所示，然后进入下一步。
2、其次，完成上述步骤后，菜单栏中选择“创建”，然后选择“查询设计”按钮。将d出“显示表”窗口，如下图所示，然后进入下一步。
3、接着，完成上述步骤后，选择“表1”并单击“添加”，如下图所示，然后进入下一步。
4、然后，完成上述步骤后，单击查询设计网格第一列中的字段行，选择“生成器”选项，打开“表达式生成器”对话框，在对话框中输入表达式“m”：Max（[Age]）-min（[Age]），单击“确定”按钮，如下图所示，然后进入下一步。
5、随后，完成上述步骤后，点击“查询工具”选项卡中“结果”命令组的“数据表视图”命令以查看查询结果，如下图所示，然后进入下一步。
6、最后，完成上述步骤后，查询结果如下图所示。这样，问题就解决了。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）