最近因需要使用云服务器来运行java项目于是开始了解其市场，查来查去发现阿里云具有学生优惠政策便十分果断地购买了一个月来尝鲜。毕竟对于首次接触的事物都是了解为主不会投入大量资金。下面就是我目前使用过程中遇到过的问题和解决方法。1.系统选择与环境搭建：　　　　(1)在系统选择方面由于我对linux系统只学过一点皮毛所以不敢贸然使用，于是windows系统就成了我的不二之选(至少在系统操作方面的问题能减少)。当我想连接我的云服务器时第一个问题出现了：我该如何连接到服务器？在查询资料后我发现了一个最适合我的办法：使用windows系统自带的远程桌面连接。在计算机一列输入云服务器的公网IP即可轻松连接。　　(2)在第一次连接后我欣喜若狂，仿佛解决了世纪难题但其实更大的难题在拐角处等待着我。之后我按查询的资料打算亲自配置java+tomcat+mysql环境但这个天真的想法毁了我刚刚得到的好心情。在配置java与tomcat时没出现太大的问题但在mysql上便问题重重，在我查询资料和认真思考后认为是缺少必要的插件，因为我目前使用的是裸机一切都需要自己搭建这对我这个服务器小白来说是灭顶之灾，但好在我发现了镜像这一功能。镜像的使用能使你免受环境搭建的痛苦，我们可以在镜像市场中挑选适合自己所需运行环境这样我们就无需自己搭建。如我的需求是向服务器上传javaweb项目，我选择的镜像就包含了java，tomcat，mysql这三大类。当我第二次连接后服务器已经搭建好了环境，同时桌面上出现了一个TXT文档里面是一串字符。经过查询和分析认定这是数据库的密码但账号还不得而知，于是我回到我选择的镜像的使用说明中查看详细信息；很遗憾他没能给我任何有用信息。我便大胆的尝试了“root”这一祖传通用用户名，没想到连接成功了！至此关于环境搭建的问题得以解决。2.对数据库的操作　　　　(1)环境搭建好后我就想着把项目所需数据库内容也导入到云服务器上，但对于DOS界面的操作实在过于繁琐我便开始寻找能让云服务器数据库可视化的工具，经过一番查询发现阿里云已经为我们制作好了一款软件DMS，我们可以在阿里云官网上找到它，下载后通过网上的使用教程我们能简易的将云服务器上的数据库添加至该程序中。　　　(2)实现数据库的可视化后我又开始查询导入数据的方法，首先我们需先把所需数据表导出为sql文件之后再DMS中点击数据方案->导入->新增任务之后选择导入到哪个数据库和导入的sql文件即可。但在这一环节存在一个小问题由于数据库版本的差异它们对编码的要求也是不同的如果你直接将导出的sql文件导入可能会报编码类问题的错误，这时我们就要注意你云服务器上的数据库要求的编码和校验规则；注意我们不仅要搞清楚编码要求也要搞清校验规则需求。编码要求和校验规则要求我们可在建表时设定。　　　　(3)之后我们需更改要导入的sql文件的编码与校验规则，使用替换功能将与编码有关的改为云服务器对应编码，将校验规则有关的改为云服务器对应校验规则。如下图我将文件中存在set后对应字符的地方替换为utf8，将文件中存在collate后对应字符的地方替换为utf8_general_ci.

最近因需要使用云服务器进行云计算一课，于是开始查阅相关的云服务，查来查去发现阿里云具有学生优惠政策便十分果断地进行注册和申请。下面就是我目前使用过程中遇到过的问题和解决方法。1.系统选择与环境搭建：　　　　(1)在系统选择方面由于我对linux系统只学过一点皮毛所以不敢贸然使用，于是windows系统就成了我的不二之选(至少在系统操作方面的问题能减少)。当我想连接我的云服务器时第一个问题出现了：我该如何连接到服务器？在查询资料后我发现了一个最适合我的办法：使用windows系统自带的远程桌面连接。在计算机一列输入云服务器的公网IP即可轻松连接。　　　　(2)在第一次连接后我欣喜若狂，仿佛解决了世纪难题但其实更大的难题在拐角处等待着我。之后我按查询的资料打算亲自配置java+tomcat+mysql环境但这个天真的想法毁了我刚刚得到的好心情。在配置java与tomcat时没出现太大的问题但在mysql上便问题重重，在我查询资料和认真思考后认为是缺少必要的插件，因为我目前使用的是裸机一切都需要自己搭建这对我这个服务器小白来说是灭顶之灾，但好在我发现了镜像这一功能。镜像的使用能使你免受环境搭建的痛苦，我们可以在镜像市场中挑选适合自己所需运行环境这样我们就无需自己搭建。如我的需求是向服务器上传javaweb项目，我选择的镜像就包含了java，tomcat，mysql这三大类。当我第二次连接后服务器已经搭建好了环境，同时桌面上出现了一个TXT文档里面是一串字符。经过查询和分析认定这是数据库的密码但账号还不得而知，于是我回到我选择的镜像的使用说明中查看详细信息；很遗憾他没能给我任何有用信息。我便大胆的尝试了“root”这一祖传通用用户名，没想到连接成功了！至此关于环境搭建的问题得以解决。2.对数据库的操作　　　　(1)环境搭建好后我就想着把项目所需数据库内容也导入到云服务器上，但对于DOS界面的操作实在过于繁琐我便开始寻找能让云服务器数据库可视化的工具，经过一查询发现阿里云已经为我们制作好了一款软件DMS，我们可以在阿里云官网上找到它，下载后通过网上的使用教程我们能简易的将云服务器上的数据库添加至该程序中。　　　　(2)实现数据库的可视化后我又开始查询导入数据的方法，首先我们需先把所需数据表导出为sql文件之后再DMS中点击数据方案->导入->新增任务之后选择导入到哪个数据库和导入的sql文件即可。但在这一环节存在一个小问题由于数据库版本的差异它们对编码的要求也是不同的如果你直接将导出的sql文件导入可能会报编码类问题的错误，这时我们就要注意你云服务器上的数据库要求的编码和校验规则；注意我们不仅要搞清楚编码要求也要搞清校验规则需求。编码要求和校验规则要求我们可在建表时设定。　　　　(3)之后我们需更改要导入的sql文件的编码与校验规则，使用替换功能将与编码有关的改为云服务器对应编码，将校验规则有关的改为云服务器对应校验规则。如下图我将文件中存在set后对应字符的地方替换为utf8，将文件中存在collate后对应字符的地方替换为utf8_general_ci.以上问题仅为我遇到的通过查询难以解决的问题，其他问题网上都有详细的说明，大家可自行查阅；同时这也仅为我短时间使用遇到的问题仅供参考日后还会通过进一步使用来继续总结。

阿里云和 Cloudera 展开密切合作，在阿里云的公有云上提供开箱即用的 CDP 平台，使得用户可以根据自己的需求，在阿里云上启用安全、合规和高可用的 CDP 平台，充分利用 CDP 平台的功能和阿里云的灵活性，来降低客户管理平台的复杂性，从而快速实现业务。选择合适的集群是在阿里云平台上使用 CDP 的第一步。CDP 配置选型不仅要考虑企业大数据使用场景、估算数据量、服务可靠性、安全等要求，还要考虑企业预算。一、CDP节点类型Cloudera 建议在生产环境中部署 CDP 多达四种机器类型：主节点-主要运行 Hadoop 主守护程序，例如 NameNode, Standby NameNode, YARN Resource Manager and History Server, the HBase Master daemon, Ranger server, Atlas Server, and the Impala StateStore Server and Catalog Server。主节点也是 Zookeeper 和 JournalNodes 的安装位置。守护程序可以共享一个服务器池。根据集群大小、角色可以在专用服务器上运行。Kudu Master Servers 也应该部署在主节点上。生产集群建议打开高可用 HA，生产集群建议在创建集群的硬件配置步骤开启高可用。如果购买时未开启高可用，在后续使用过程中开启高可用功能。Master 节点主要用来存储 HDFS 元数据和组件 Log 文件，属于计算密集型，对磁盘 IO 要求不高。HDFS 元数据存储在内存中，建议根据文件数量选择32 GB以上内存空间。工作节点-主要用来存储数据和执行计算，运行 HDFS DataNode,、YARN NodeManager、HBase RegionServer、Impala impalad、Search worker daemons 和 Kudu Tablet Servers。推荐使用 SSD 云盘存储数据。工具节点-运行 Cloudera Manager 和 Cloudera Management Services。它还可以运行托管的 MariaDB（或其他受支持的）数据库实例，Cloudera Manager、Hive、Ranger 和其他与 Hadoop 相关的项目将使用该数据库实例。边缘节点-包含所有面向客户端的配置和服务，包括 HDFS、YARN、Impala、Hive 和 HBase 的网关配置。Hue、 Oozie、 HiveServer2 和 Impala HAProxy、 HiveServer2 和 Impala HAProxy server 充当通往外部应用程序（如商务智能(BI)工具）的网关也部署在边缘节点上。边缘节点也称为网关节点。注意：在较小的集群中边缘和工具节点可以合并在一起。阿里云上的 CDP 存储目前支持 ESSD 云盘。底层存储目前支持 HDFS 和 Kudu。HDFS 的数据可用性由云盘或本地盘存储的可靠性来保证。二、CDP 集群角色分布没有启用 HA 的3-10个工作节点角色分配启用 HA 的3-20个工作节点角色分配三、设置对基于阿里云部署的 CDP 的访问权限在阿里云或者内外网环境中，Cloudera 的平台产品 CDP 需要访问很多 Web UI，但系统网络可能仅支持 SSH 访问(22端口)。要访问 Cloudera Manager（7180端口）或者其他服务，可以通过下列两种方式：在客户端计算机上设置 SOCKS（套接字安全协议）代理。Cloudera 建议您使用此选项。将 CDP/CDP 部署到阿里云之后，将入站规则添加到阿里云实例中的网络安全组。配置 SOCKS 代理 SOCKS5 协议是作为客户端和服务器进程实现的，它可以遍历IP网络防火墙。配置 SOCKS 代理后，浏览器使用公有云网络（通过代理服务器）解析 DNS 查找，并允许您使用内部 FQDN 或专用 IP 地址连接到服务。 使用这种方法，您可以完成以下任务：设置到网络上主机之一的单个 SSH 隧道，并在主机上创建 SOCKS 代理。 更改浏览器配置，以通过 SOCKS 代理主机执行所有查找。网络先决条件在使用 SOCKS 代理连接到集群之前，请验证以下先决条件：您必须能够从公共 Internet 或您要从其连接的网络中访问要代理的主机。您要代理的主机必须与您要连接的 Cloudera 服务位于同一网络上。例如，如果您使用的是 Cloudera CDP 产品，请通过 SSH 隧道连接到 Cloudera Manager 主机。​​​启动 SOCKS 代理Linux要通过 SSH 启动 SOCKS 代理，请运行以下命令：ssh -i your-key-file.pem -CND 1080 the_username_you_specified@publicIP_of_VM该命令使用以下参数：-i your-key-file.pem 指定 SSH 到 Cloudera CDP/EDH 服务器所需的私钥的路径。如果使用 SSH 密码，则省略。C 设置压缩。N 建立后禁止执行任何命令。D 在端口上设置SOCKS代理。1080 用于在本地设置 SOCKS 代理的端口。Windows按照 Microsoft 网站上的说明进行操作。参考链接：https://docs.microsoft.com/zh-cn/archive/blogs/pliu/ssh-tunnel-to-endpoints-in-azure-vnet-from-windows配置 Google Chrome 浏览器以使用代理默认情况下，Chrome 浏览器会按配置文件使用系统范围的代理设置。要在没有这些设置的情况下启动 Chrome，请通过命令行打开 Chrome并 指定以下内容：SOCKS 代理端口。该端口必须与启动代理时使用的端口相同。配置文件。下面的示例创建了一个新的配置文件。使用以下命令之一创建配置文件并启动与当前任何正在运行的 Chrome 实例不冲突的 Chrome 的新实例。Linux/usr/bin/google-chrome \ --user-data-dir="$HOME/chrome-with-proxy" \ --proxy-server="socks5://localhost:1080"Mac OS X"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \ --user-data-dir="$HOME/chrome-with-proxy" \ --proxy-server="socks5://localhost:1080"微软Windows"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" ^ --user-data-dir="%USERPROFILE%\chrome-with-proxy" ^ --proxy-server="socks5://localhost:1080"在此 Chrome 会话中，您可以使用私有 IP 地址或内部 FQDN 连接到 Cloudera CDP 可访问的任何主机。这样就可以通过内网访问 Cloudera Manager 和其他 Web UI 了也可以通过 CM 中的 web UI 跳转直接跳转过去。​网络安全组警告：除概念验证以外，不建议将此方法用于任何其他目的。如果没有仔细锁定数据，那么黑客和恶意实体将可以访问这些数据。钉钉扫描下方二维码加入阿里云 Cloudera 企业数据云交流群一起参与讨论吧！

10月20日，2021云栖大会上，阿里云数据库事业部负责人李飞飞发表《云原生数据库2.0：企业级一站式数据管理》主题演讲，分享了云原生数据库从1.0到2.0向企业级一站式数据管理服务演进的趋势，并宣布重磅升级自研云原生关系型数据库PolarDB，实现内存池化、多主架构、HTAP实时分析等创新功能，进一步引领云原生数据库技术的持续创新。 自动驾驶数据库智能化与安全的RDS让企业级数据库服务触手可及 阿里云RDS数据库基于AI以及机器学习技术实现了“自动驾驶”能力，更加简单易用、好运维、好部署。智能化与安全的RDS让企业级数据库服务触手可及，数据库可以自动升级、自动调优、自动压测、SQL诊断优化、自动扩缩容、自动限流等。其中，SQL自动限流可以保障突发流量场景下数据库的稳定运行，为问题定位争取宝贵的时间。此外，阿里云RDS PostgreSQL是全球第二家实现基于Intel SGX硬件实现全加密功能的数据库，用户可以直接在公共云上购买使用。 三层解耦PolarDB将云原生进行到底 阿里云自研云原生关系型数据库PolarDB推出重磅升级，实现内存池化、多主架构、HTAP实时分析等创新功能，进一步引领云原生数据库技术的持续创新。本次技术升级中，PolarDB实现了三项创新：第一，业内首次实现内存与计算、存储的三层解耦，实现内存池化，使得弹性能力呈数量级提升，同时大幅度降低成本；第二，上线多主架构，进一步提升可用性、并发处理、弹性能力，高效应对像“双11”一样的流量洪峰；第三，成为真正的HTAP数据库系统，可同时处理OLTP和OLAP型混合负载。 一体化分布式PolarDB-X全面开源 阿里云正式开源云原生分布式数据库PolarDB-X的源代码，将自研云原生分布式核心技术分享出来，进一步推动云原生分布式数据库发展。本次开源遵循Apache v2(计算层)和GPL v2(存储层)开源协议，以全共享并尊重原作者著作权的模式开源，用户可以直接使用或基于阿里云开源数据库产品提供二次分发的商用产品和服务。该项目现已在阿里云官网及Github上发布。“我们将阿里最核心的云原生数据库技术进行开源，希望开发者和客户通过开源版本快速使用阿里云数据库产品技术，并参与到技术产品的迭代过程中来，共建云原生分布式数据库生态。”阿里云数据库负责人李飞飞表示。计算层https://github.com/apsaradb/GalaxySQL存储层 https://github.com/apsaradb/GalaxyEngine 离在线一体化AnalyticDB（ADB）云原生+MPP数据库，让数据分析实时化、在线化 AnalyticDB持续深化云原生+离在线一体化，存储支持在线高并发低延迟读写以及离线大吞吐读写；计算引擎支持同一内存池、算子级时间公平调度的在离线计算混合负载、向量化和Code Gen，实现一个SQL引擎同时支持高并发交互式分析以及离线ETL处理。AnalyticDB MySQL满足了对离在线一体化的场景需求，具备三大亮点：第一，高效执行执行引擎，在标准的TPC-DS的测试集，通过向量化加编译执行，指令集优化性能大幅提升，带来5倍以上的性能提升；第二，混合负载管理，引入算子时间片调度，打开混合负载保护后，离线任务对在线查询的干扰可以大幅降低，压测中降低到20倍以内。第三，实时增删改查，在标准的YCSB的集成测试上，相对开源HBase有2倍以上的性能优势。 此外，阿里云还发布云原生数据仓库AnalyticDB PG全新云原生架构版本，采用计算存储分离架构，存储计算完全解耦，支持秒级扩缩容，存储按量计费，最高可降低10倍存储成本。 库仓一体DMS让数据自由流动 企业级一站式在线数据管理平台DMS将多元异构的在线数据库实例实现统一管理，提供数据从脱敏到开发到DevOps等一系列企业级数据库管理能力。目前已有10万级周活开发者，支持27种数据源，拥有24万企业全域资产，管理60万以上实例，65万以上的数据集成链路以及15种脱敏算法实时集成，真正做到库仓一体，让数据在数据库和数据仓库无缝流转。 敏捷交付，无缝集成DBStack让云原生数据库无处不在 为了更好服务政企市场，阿里云正式发布一款重磅数据库产品DBStack，助力金融、政务、运营商、交通、电力等行业客户替换传统商业数据库，在自有基础设施上构建稳定、安全、经济的全场景数据库解决方案，加速业务数字化转型，实现高速增长。政企客户在自有数据中心或者IaaS平台上部署DBStack，相当于把云上的云原生分布式数据库能力搬到云下，在不上公共云的情况下，即可充分享受云原生数据库稳定、安全、低成本的产品能力。同时，DBStack还提供数据库一键迁移能力，方便政企客户替换传统商业数据库，快速上云。作为全球数据库领导者，为推动数据库产业发展与人才培养，阿里云还发布阿里云数据库ACP认证，包含关系型数据库和数据仓库两个方向，通过系统化培训与认证体系，培养更多数据库专业人才。

PolarDB-X 2.0视频解读：https://yqh.aliyun.com/live/polardbx2021透明分布式，是PolarDB-X即将发布的能力，它能让应用在使用PolarDB-X的过程中，犹如使用单机数据库一般的体验。与传统的中间件类型的“分布式数据库”相比，有了透明分布式能力的PolarDB-X，不再需要应用考虑分区键的概念，应用可以完全将单机MySQL上开发的建表语句、应用代码直接迁移到PolarDB-X上运行起来。本文将为大家介绍PolarDB-X透明分布式的新体验。在PolarDB-X上安装一个WordPressWordPress是一个开源的博客软件，它使用MySQL作为其数据库。操作是在PolarDB-X上安装一个WordPress，来体验PolarDB-X的透明分布式能力。我们将遵循简单的三步走：不修改DDL直接建表不修改应用直接跑起来做下压测，做下调优总结如下：使用官方的WordPress镜像，不做任何修改，其安装程序就能自动的在PolarDB-X上完成建表、数据初始化等工作，其使用的都是标准的MySQL语法。对此WordPress进行压测，PolarDB-X的各项监控数据显示，各节点处于的负载、数据量均处于均衡的状态。通过PolarDB-X提供的SQL分析、DAS等工具，可以方便的找到系统中热点SQL。DBA可以直接通过创建索引、修改数据分布等DDL语句对系统性能做进一步的优化，不需要修改应用。PolarDB-X实现透明分布式的武器下面为大家分享下，PolarDB-X是如何实现透明分布式的。透明数据分区PolarDB-X是一个典型的Share Nothing的分布式数据库，其简化架构如下：其核心组件为无状态的计算节点CN，与有状态的存储节点DN。要了解PolarDB-X的透明分布式能力，首先要了解数据在PolarDB-X上是如何分布的。在PolarDB-X中，一个表由多个索引组成，包括主键、二级索引等。PolarDB-X会对每个索引进行独立的进行分区，其分区键为索引的key。例如一个典型的电商场景，订单表，拥有一个主键（id），两个索引（seller_id与buyer_id）：create table orders ( id bigint, buyer_id varchar comment '买家', seller_id varchar comment '卖家', primary key(id), index sdx(seller_id), index bdx(buyer_id) )对于主键索引，会按照id对其进行分区对于索引sdx，会按照seller_id进行分区对于索引bdx，会按照buyer_id进行分区如下图所示：对索引进行分片之后，PolarDB-X会将这些分片打散到不同的存储节点里，并会按照数据量等信息进行负载均衡，如下图所示：在PolarDB-X中，建表语句中可以不考虑分区键，PolarDB-X也能自动的对表进行分片与负载均衡。因此，应用迁移PolarDB-X时，可以将单机MySQL中的建表语句导出，不需要修改直接在PolarDB-X中执行即可。透明的分布式事务分布式事务是PolarDB-X中的最重要的基础能力，它广泛的应用于业务内，避免了业务对事务代码进行改造；同时，PolarDB-X内部也用事务来实现索引。PolarDB-X的分布式事务有以下几个特征：与Spanner一样，满足外部一致性这种最强的一致性级别语法与MySQL完全兼容，无需对应用进行改造行为上支持兼容MySQL的RC与RR级别PolarDB-X分布式事务的原理我们专栏有很多介绍的文章，在此不再赘述。对其原理感兴趣的同学可以参考这几篇文章：https://zhuanlan.zhihu.com/p/329978215https://zhuanlan.zhihu.com/p/338535541https://zhuanlan.zhihu.com/p/355413022Online DDLPolarDB-X支持类型丰富的Online DDL，这里介绍一些有代表性的DDL类型。索引维护与单机MySQL的索引有所差异，PolarDB-X的索引均为全局索引，包含以下几种类型：普通索引唯一索引聚簇索引其中聚簇索引是PolarDB-X相对于MySQL的一种新类型的索引，它会包含表中的所有列，从而避免了回表的代价。PolarDB-X中对索引的创建都通过DDL来完成，并且都是Online的，不会阻塞业务。例如：创建一个普通的索引：CREATE INDEX idx1 ON t1(name)创建一个聚簇的索引：CREATE CLUSTERED INDEX idx1 ON t1(name)INSTANT ADD COLUMN加列操作是业务中最为常见的DDL类型。在MySQL中，加列操作的耗时是与数据量相关的（MySQL8.0中在表的最后面加列是INSTANT的）。在PolarDB-X中，在任意位置加列都是INSTANT的，这个代表加列操作为恒定的秒级耗时，与数据量无关，不会对业务产生任何影响。分区调整PolarDB-X支持4种表的分布策略，Hash、Range、List、Broadcast。由于Hash能避免连续写入的热点，PolarDB-X默认使用Hash策略，大多数情况下，此策略能够很好的满足系统的性能需要。但是如果业务在运行期间，希望选择合适的分区策略来提升系统性能，在PolarDB-X中可以方便的通过DDL语句进行调整，PolarDB-X会按照新的分区策略重新组织表的数据。例如：修改表的分区策略为Hash：ALTER TABLE t1 PARTITION BY HASH(name)修改表的分片数为32：ALTER TABLE t1 PARTITION BY HASH(name) PARTITIONS 32将表变为广播表：ALTER TABLE t1 BROADCAST修改表的分区策略为RANGE：ALTER TABLE t1 PARTITION BY RANGE(id)任意两种分区策略之间都可以通过DDL语句进行转换：回填速度自适应想必很多同学有过这样的经验：一个超大的表进行DDL操作，由于数据量比较大，这个DDL操作无法在一天内完成，为了避免对业务影响，人肉在白天业务高峰期来临的时候，调整参数，降低DDL的回填速度，晚上在业务高峰期结束后，提高DDL的回填速度。PolarDB-X中的回填，会根据当前的系统负载，自动调节速度。例如：在这个例子中，分了四个阶段：开始没有业务负载，DDL回填速度上升到25W行/s业务负载开始上升，DDL回填速度迅速下降到13W行/s业务TPS稳定在1W5，DDL回填速度稳定在13W行/sDDL结束后，业务TPS稳定在1W6从这个例子中，我们可以看到PolarDB-X DDL的回填速度会自动根据业务负载进行调整，并且DDL期间，对业务的TPS影响很小。让Online更Online为了进一步减少DDL期间对业务的影响，PolarDB-X还使用了多项技术，例如：元数据多版本，详见：https://zhuanlan.zhihu.com/p/347885003可暂停、可取消MDL死锁检测我们会在今后的文章里详细介绍这些技术的细节，请关注我们的知乎专栏：https://www.zhihu.com/org/polardb-x总结PolarDB-X的透明分布式能力，将极大的减少应用从单机数据库迁移分布式数据库的成本。同时，我们未来也会让它变得更透明，我们正在做的一些事情包括：更精细的调度策略热点数据的可视化展示，与SQL审计分析联动的智能诊断在有全局索引的情况下，支持分区级的truncate数据的按时间滚动、清理等等

------------------------------------------- 系统模块权限管理：点开二级菜单进入三级菜单显示 角色(基础权限)和按钮权限角色(基础权限): 分角色组和角色,独立分配菜单权限和增删改查权限。（一个用户可以多个角色）按钮权限: 给角色分配按钮权限。按钮管理：自定义按钮管理，维护按钮shiro权限标识等菜单管理：N级别自定义菜单，选择菜单图标，菜单状态显示隐藏（递归处理）数据字典：N级别，支持多级别分类。内设编号，排序等日志管理：记录用户登录退出和一些重要操作记录在线管理：websocket技术，实时检测在线用户列表，统计在线人数,可强制用户下线 同一用户只能在一个客户端登录系统用户：对各个基本的用户增删改查，导出到excel表格，批量删除代码生成：生成完整的模块代码，并保留生成记录模版，可复用 （超强悍开发利器）正向生成: 生成完整的模块，html页面、处理类、mapper层、service层、myabaits的xml 建表的sql脚本等反向生成: 任意连接其它数据库(mysql、oracle、sqlserver)，根据表反射生成本系统的模块9 模版管理：代码在线编辑器，管理模版，保存编辑记录，一键还原，代码生成器如虎添翼10.性能监控：监控整个系统的性能，SQL监控，SQL防火墙，URL监控，SPRING监控，SESSION监控等11.网络监控：实时监控服务器网络接收数据包速度，动态图表展示12.服务器监控：实时监控jvm内存，服务器内存，CPU使用率。 单次读取服务器其它配置等信息13.系统设置：修改系统名称，每页显示条数, 邮件服务配置，站内信配置站内信：收信箱和发信箱，websocket技术通讯技术做的及时收信提醒，可配置语音提示来信---------------------------通讯模块 单聊群聊发图片发文件 离线消息保留聊天记录好友管理：搜索、添加、删除、拉黑好友，查看好友资料好友分组：自定义好友分组我的群组：创建群组，搜索申请加入别人的群，踢出群成员，管理群聊天记录------------------------------fhadmin.cn数据库备份：可备份单表(sqlserver不支持)、整库，支持本地和远程备份(java界面编程技术，socket编程技术)备份定时器：quartz 强大的任务调度，多线程备份数据库，任务启动关闭异步操作数据库还原：历史备份记录，还原数据库 or 单表(sqlserver不支持)，统计备份时间和文件大小SQL编辑器：强大的SQL编辑器，支持编辑语句复杂查询语句，生成动态报表，可导出excel----------------------------fhadmin.cn请假申请：添加请假单，走工作流请假模型流程组织机构：N级别，公司or部门管理员工管理：和组织机构部门管理，可以绑定登录系统用户，授权数据权限工作日志：填写日常工作内容，此模块绑定数据权限----------------------------fhadmin.cn接口测试：POST or GET 方式检测系统接口，参数加密，json返回结果，计算服务器响应时间通用申请：添加通用单，进行选择流程标识，走相应模型流程-------------------------------------------------------fhadmin.cn-----------自定义表单定义模版：拖拽左侧表单元素到右侧区域，编辑表单元素，保存表单模版表单模版：编辑维护表单模版，复制表单模版，修改模版类型，预览表单模版我的表单：选择表单模版，编辑表单规则，是否上传图片、附件、开启富文本、挂靠流程开关等表单数据：从我的表单进去可增删改查表单数据，修改表单规则挂靠记录：记录表单数据和流程实例ID关联记录，可删除

背景随着云原生的普及，各家公司都通过K8S实现了服务的容器化，极大的简化了开发运维人员的工作，是目前最为常用的基础服务。同时，K8S集群中的各项基础服务能够通过metrics接口导出Prometheus格式的多种指标，方便观察当前系统状态，及时发现问题。用户将K8S集群指标采集到日志服务SLS时序存储之后，可以随时查看系统历史及当前指标，还可以通过SLS内置仪表盘或者Grafana构建监控大盘，方便观察系统情况。但是随着系统规模以及负载成倍增加，复杂的指标查询以及监控大盘的渲染开始变慢，进而影响操作体验。指标预聚和指标预聚合指在后台定时运行批处理任务，按照一定的规则将多条系统指标合并为一条，减少所需指标计算涉及到的数据量，加快计算结果的产出。因而在观察指标确定的情况下，使用指标预聚合可以很好的解决前面遇到的问题。我们以CPU指标利用率的计算为例：可以获取到K8S的两项指标：CPU累计使用时长container_cpu_usage_seconds_total以及CPU配额container_spec_cpu_quota。为了计算单位事件内CPU的利用率：计算单位时间累计利用率： container_cpu_usage_minutes_total: sum(rate(container_cpu_usage_seconds_total{image!=""}[5m])) by (namespace,pod_name)；计算单位时间内的总CPU配额：container_spec_cpu_cores: (sum(container_spec_cpu_quota{image!=""}/100000) by (namespace,pod_name))；计算单位的CPU利用率：container_cpu_usage: container_cpu_usage_minutes_total: container_cpu_usage_minutes_total / container_spec_cpu_cores * 100整条链路冗长而且速度慢，我们可以通过预先计算container_cpu_usage_minutes_total和container_spec_cpu_cores来加快计算速度。本文主要介绍第一种方案，可以实现：降低分析延迟：预计算多项常用系统指标，加快计算速度；优化数据存储：只存储关心的聚合指标，定期清理详细指标；原理即为使用SLS提供的ScheduledSQL服务，在后台定时运行SQL计算任务，将统计结果存入时序存储。K8S指标K8S指标众多，首先需要确定常用的监控指标，得到预聚合计算表达式。本文选取了Prometheus Operator中部分常用指标的计算表达式，更多的指标用户可以根据需求自行构建。指标名称说明cpu_resource_request_percentageCPU Request水位mem_resource_request_percentageMem Request水位kubelet_running_pod_percentagePod水位api_service_success_percentageAPIServer请求成功率CPU Request水位* | select promql_query_range('(sum(kube_pod_container_resource_requests_cpu_cores))/(sum(kube_node_status_allocatable_cpu_cores)) * 100') from metrics limit 1000Mem Request水位* | select promql_query_range('(sum(kube_pod_container_resource_requests_memory_bytes))/(sum(kube_node_status_allocatable_memory_bytes)) * 100') from metrics limit 1000Pod水位* | select promql_query_range('(sum(kubelet_running_pod_count)-33)/(sum(kube_node_status_allocatable_pods)-330) * 100') from metrics limit 1000APIServer请求成功率* | select promql_query_range('sum(irate(apiserver_request_count{job="apiserver", code=~"20.*"}[5m]))/sum(irate(apiserver_request_count{job="apiserver"}[5m]))') from metrics limit 1000ScheduledSQL实践计算配置资源池有免费（Project 级别 15 并行度）、增强型（收费，但资源可扩展，适用于大量计算且有 SLA 要求的业务场景）两种，按照你的需求来设置即可。写入模式写入模式有三种选择，当源为日志库时，可以选择日志库导入日志库以及日志库导入时序库；当源为时序库时，可以选择时序库导入时序库。因为K8S指标为时序库，计算结果为时序数据，所以此处选择时序库导入时序库。结果指标名指定计算结果的指标名称，默认选择metric列的值作为指标名称。此处需要注意，如果metric列的结果包含多种不同的指标名称，将会全部重命名为此处配置的指标名称。因为该例子中的指标名称为null，所以配置为cpu_resource_requests。哈希列如果时序库中同一label的数据写入到固定的hard中，可以增强局部性，提升查询效率。因此可以选择常用的过滤标签，作为哈系列，使给定标签相同的指标存入同一shard中。此处留空。附加labels为计算结果添加额外的属性，方便后续查询，此处留空。调度配置设置 SQL 每 5 分钟执行一次，每次执行处理最近 5 分钟窗口的数据。注意：1. 设置延迟执行参数，上游时序库的数据到来可能延迟，建议设置大一些的值做等待来保证计算数据的完整性。2. SQL运行超过指定次数或指定时间后，这一次的SQL实例会失败并继续下一个实例的调度。任务管理在SLS控制台可以查看之前创建的ScheduledSQL作业。在作业管理页面内，可以查看到每一次执行的实例列表。每个实例信息中有 SQL 查询区间，如果任务失败（权限、SQL 语法等原因）或 SQL 处理行数指标为 0（数据迟到或确实没有数据），可以对指定实例做重试运行（失败告警功能开发中）。效果计算完成之后，可以在时序库中查询结果指标。CPU Request水位API Server请求成功率总结通过SLS提供的ScheduledSQL功能，用户可以轻松聚合时序数据，存入到SLS的时序库中，满足用户监测系统指标的需求。

背景对象存储OSS是阿里云提供的云存储服务，能够以低成本为用户提供高可靠性的海量数据存储服务。作为基础服务，用户需要时刻关注OSS的使用状况，检测异常状态，从而及时作出响应。阿里云日志服务（SLS）是云原生观测分析平台，为Log/Metric/Trace等数据提供大规模、低成本、实时平台化服务。一站式提供数据采集、加工、分析、告警可视化与投递功能，全面提升研发、运维、运营和安全等场景数字化能力。用户在访问对象存储 OSS 的过程中，会产生大量的访问日志。SLS允许一键接入OSS 访问日志，方便用户完成操作审计、访问统计、异常事件回溯和问题定位等工作。问题一：存储空间持续增加以 1000 QPS 的请求量计算，每条日志 1500 Bytes，一个月累计后达到 3.8 TB。但 访问日志随时间推移逐渐从温数据变为冷数据，这带来一笔不小的存储开销。问题二：分析计算消耗大假设对 30 天的数据分析小时级流量特征，如果每次对全量数据做即时分析，计算成本是巨大的，计算延时的增加也影响了体验。以 bucket、method 分组计算小时级流量特征为例：* | select (__time__ - __time__ % 3600) as dt, bucket, http_method, sum(request_length)/1024.0/1024.0 as request_MB, sum(response_body_length)/1024.0/1024.0 as response_MB, avg(response_time) as avg_latency group by dt, bucket, http_method order by dt asc limit 10000随着查询时间范围增加，计算引擎需要扫描更多的数据量做计算，增加了资源开销与分析延时。数据查询范围扫描日志条数 计算耗时24 hours5,153,4261,767ms30 days35,754,3844,636ms方案本文介绍一种将日志转为指标的方案，允许用户快速查询分析OSS指标。常见的Log转Metric的方法可以有两种:聚合日志产生指标，类似sql做group by以后产生对应的统计值。将日志格式做格式转换，使其符合Metric格式. 对应SLS数据加工e_to_metric场景本文主要介绍第一种方案，可以实现：降低分析延迟：将日志数据转为时序数据，存入时序存储分析；SLS时序库针对指标场景做了大量优化；优化数据存储：只存储监控相关数据，移除多余字段；能够使用Prometheus生态：时序存储支持Prometheus查询语句，同时支持Prometheus 查询API；原理即为使用SLS提供的ScheduledSQL服务，在后台定时运行SQL计算任务，将统计结果存入时序存储。OSS指标数据OSS访问日志中包含多种信息，首先需要确定日志信息能够计算得到的指标数据种类。本文给出了部分常用指标，更多的指标用户可以根据需求自行构建。指标标签我们统一使用：bucket, bucket_location, bucket_storage_type, http_method, http_status, object, operation字段。用户可以根据自己的需用访问次数计算分钟级不同类型OSS请求的次数。计算SQL*|select bucket, bucket_location, bucket_storage_type, http_method, http_status, object, operation, (__time__ - __time__ % 60) as time, count(1) as request_count from log group by bucket, bucket_location, bucket_storage_type, http_method, http_status, object, operation, time请求数据量计算分钟级OSS请求数据量。计算SQL*|select bucket, bucket_location, bucket_storage_type, http_method, http_status, object, operation, (__time__ - __time__ % 60) as time, sum(content_length_in) as request_size from log group by bucket, bucket_location, bucket_storage_type, http_method, http_status, object, operation, time响应数据量计算分钟级OSS响应数据量。计算SQL*|select bucket, bucket_location, bucket_storage_type, http_method, http_status, object, operation, (__time__ - __time__ % 60) as time, sum(content_length_out) as response_size from log group by bucket, bucket_location, bucket_storage_type, http_method, http_status, object, operation, time响应时间计算分钟级OSS平均响应时间。计算SQL*|select bucket, bucket_location, bucket_storage_type, http_method, http_status, object, operation, (__time__ - __time__ % 60) as time, avg(response_time) as response_time from log group by bucket, bucket_location, bucket_storage_type, http_method, http_status, object, operation, time为了便于计算，我们将上述多条SQL合并为一条，一次性计算所有指标。*|select bucket, bucket_location, bucket_storage_type, http_method, http_status, object, operation, (__time__ - __time__ % 60) as time, count(1) as request_count, sum(content_length_in) as request_size, sum(content_length_out) as response_size, avg(response_time) as response_time from log group by bucket, bucket_location, bucket_storage_type, http_method, http_status, object, operation, timeScheduled SQL 实践计算配置资源池有免费（Project 级别 15 并行度）、增强型（收费，但资源可扩展，适用于大量计算且有 SLA 要求的业务场景）两种，按照你的需求来设置即可。写入模式写入模式有三种选择，当源为日志库时，可以选择日志库导入日志库以及日志库导入时序库；当源为时序库时，可以选择时序库导入时序库。因为oss访问数据为日志库，计算结果为时序数据，所以此处选择日志库导入时序库。指标列指标列用于选择计算结果列，类型必须为数字，这里选择request_count, request_size, response_size以及response_time，分别表示请求次数，请求大小，响应大小以及响应延迟。这里需要注意的是，如果结果中某行数据的指标列无效（无法转为数字），ScheduledSQL任务会忽略该错误，并继续执行。LabelsLabels选择作为指标标签的列，类型没有限制，这里选择bucket, bucket_location, bucket_storage_type, http_method, http_status, object, operation。哈希列如果时序库中同一label的数据写入到固定的hard中，可以增强局部性，提升查询效率。因此可以选择常用的过滤标签，作为哈系列，使给定标签相同的指标存入同一shard中。这里选择bucket。时间列时间列用于指定该条指标的具体时间，类型必须为数字，这里直接使用time列即可。调度配置设置 SQL 每 5 分钟执行一次，每次执行处理最近 5 分钟窗口的数据。注意：1. 设置延迟执行参数，上游 Logstore 的数据到来可能延迟，建议设置大一些的值做等待来保证计算数据的完整性。2. SQL 运行超过指定次数或指定时间后，这一次的 SQL 实例会失败并继续下一个实例的调度。任务管理在SLS控制台可以查看之前创建的ScheduledSQL作业。在作业管理页面内，可以查看到每一次执行的实例列表。每个实例信息中有 SQL 查询区间，如果任务失败（权限、SQL 语法等原因）或 SQL 处理行数指标为 0（数据迟到或确实没有数据），可以对指定实例做重试运行（失败告警功能开发中）。效果计算完成之后，可以在时序库中查询oss访问指标。不同Bucket请求次数不同类型请求次数不同Bucket平均请求延迟总结通过SLS提供的ScheduledSQL功能，用户可以轻松将日志数据转为时序数据，存入到SLS的时序库中，满足用户监测系统指标的需求。更多内容请参考：

作者 | 祥光来源 | 阿里技术公众号一 引言女娲是飞天分布式系统中提供分布式协同的基础服务，支撑着阿里云的计算、网络、存储等几乎所有云产品。在女娲分布式协同服务中，一致性引擎是核心基础模块，支持了Paxos，Raft，EPaxos等多种一致性协议，根据业务需求支撑不同业务状态机。如何保证一致性库的正确性是一个很大挑战，我们引入了TLA+、Jepsen等工具保证一致性库的正确性。本文即从程序员视角介绍形式化验证工具TLA+。从理论上证明一个程序或者算法的正确性往往是困难的，工程中一般使用测试来发现问题，但再多的测试也无法保证覆盖到了所有的行为，那些没覆盖到的行为就成为潜在的隐患，一旦在线上再暴露出来，往往会带来不可预期的结果。形式化验证正是为了解决这样的问题，它使用计算机强大的计算能力，暴力的搜索所有可能的行为，检查是否满足事先设定的属性，任何不符合预期的行为都能被发现，从根本上保证算法的正确性。二 TLA+简介TLA+(Temporal Logic of Actions) 是Leslie Lamport开发的一门形式化验证语言，用于程序的设计、建模、文档和验证等，特别是并发系统和分布式系统。TLA+的设计初衷是用简单的数学理论和公式精准地对系统进行描述。TLA+及其相关工具有助于消除程序中很难找到、纠错成本高的基本错误。使用TLA+对程序进行形式化验证，首先要用TLA+对程序进行描述，这样的描述称为规范(Specification)。有了Specification以后就可以使用TLC模型检查器来运行它，运行的过程会遍历所有可能的行为，检查Specification中设定的属性，发现非预期的行为。TLA+基于数学，使用的是数学思维，与任何编程语言都不相似。为了降低TLA+的门槛，Lamport又开发了PlusCal语言，PlusCal与编程语言类似，可以很方便的描述程序逻辑，并且借用TLA+提供的工具可以直接将PlusCal翻译成TLA+。大多数工程师会发现PlusCal是开始使用TLA+的最简单方法，但简单带来的代价就是PlusCal不具备TLA+的一些功能，有时不能像TLA+那样构造复杂的模型，因此PlusCal还不能取代TLA+。先使用PlusCal编程语言完成基本的逻辑，然后进一步基于生成的TLA+代码再修改，可以简化TLA+的开发。三 TLA+应用TLA+在学术界和工业界都有着广泛的应用。TLA+ Examples给出了一些使用TLA+验证过的分布式算法和并发算法。在分布式算法和并发算法的研究领域，提出一个新的算法或者改进一个现有的算法，TLA+验证基本是标配。很多分布式算法论文在非形式化的论证介绍之外, 会附带TLA+的Specification来证明自己的算法是经过形式化验证的。对TLA+比较熟悉的业内人士来说，直接看TLA+的Specification甚至比看大段的论文理解的更快，对于论文的语言描述没有看明白，或者觉得有歧义的时候，查看TLA+的Specification对照着理解，有时候是阅读论文的一把利器，甚至有时候一些算法细节只能在TLA+的Specification里看到。由于Specification是逻辑严密滴水不漏的，可以更好的作为实现的指导。Lamport的TLA+主页上列出了一些TLA+在工业界的应用。以Amazon为例，Amazon AWS的一些系统的核心算法就使用了TLA+来做形式化验证，如表1列出了TLA+给AWS的一些系统找出的问题，其中涵盖了一些非常核心的组件，这些核心组件的问题一旦在线上暴露，造成的损失将是不可估量的。正是如此，现在分布式云服务的核心算法使用TLA+来对设计做验证已经成为行业标准了，所以作为云服务的从业者或者对此感兴趣的同学，熟悉TLA+绝对是不可或缺的加分项。表1：TLA+给AWS的系统找出的问题四 TLA+入门在VS Code中安装TLA+插件就可以开始使用TLA+了。这里先以一个简单的示例入门TLA+。考虑一个单比特位的时钟，由于只有一个比特位，只能取值0或者1，其行为只有如下两种情况：0 -> 1 -> 0 -> 1 -> 0 -> ...1 -> 0 -> 1 -> 0 -> 1 -> ...我们如何用TLA+来描述这个时钟呢？为了更容易入门，先用更方便工程师入门的PlusCal来描述：图1：单比特时钟的PlusCal描述图1是单比特时钟的PlusCal描述，相信具有编程功底的同学都能轻易看懂。这段PlusCal代码可以直接使用TLA+提供的工具翻译成TLA+代码：图2：单比特时钟的TLA+描述有了上面的PlusCal的基础，理解这一段TLA+也不难，重点在于Spec的理解。Spec定义了系统的行为，如图3描述了单比特时钟的行为，Init将clock初始化为0或1，Tick让clock在0和1之间来回跳转，Stutter让clock保持不变。TLA+运行的过程其实就是在图上做遍历。图3：单比特时钟的行为要让这段TLA+跑起来，上述TLA+代码需保存至clock.tla文件，此外还需要编写一个如图4所示的clock.cfg文件，clock.cfg文件内容很简单，它注明要运行的Specification是哪个，要检查的Invariant是哪个。图4：clock.cfg文件内容有了这两个文件，就可以用TLC来运行了，运行结束后得到如图5所示的结果，图中展示了一些统计信息。图5：运行结果五 TLA+原理为了理解TLA+的运行原理，弄清楚它是怎么遍历的，我们可以在运行的时候加上一些参数，让TLC输出状态图。比如我们运行图6所示的一段TLA+代码，图7是运行所需要的cfg文件。这个例子试图找出用面值为1、2和5的钱组合出19块钱的所有组合方式。图6：money.tla图7：money.cfg运行结束后可以得到如图8所示的状态图，图中的顶点为状态，共20种状态，money=0为初始状态，money=19为终止状态，图中的边为动作，共4种动作：Add(1)、Add(2)、Add(5)和Terminating。图8：状态图TLA+的运行是完全串行的，运行的的过程即在状态图上做图的遍历，每遍历到一个状态，就检查一下当前状态是否满足事先设定的不变式，满足则继续遍历，不满足则立即报错。TLA+会尝试所有的遍历路径，不错过任何一种行为。我们知道图的遍历方式有深度优先和广度优先两种，TLA+默认广度优先遍历，也可配置成深度优先模式或者随机行为模式，深度优先模式需要给定一个最大深度。现在我们知道了TLA+的原理实际上就是状态图的遍历并检查的过程，这样的过程看似简单，却能覆盖到算法所有的路径，不漏掉任何一种行为。实际我们经常使用TLA+检查算法的Safety和Liveness属性。六 TLA+并发到这里相信读者对TLA+的原理已经有了初步的了解，但细心的读者可能心中还有一个很大的疑问：TLA+运行过程是完全串行的，那么串行运行的TLA+如何模拟并发算法或者分布式算法呢？对于串行算法来说，算法中的动作是Totally Ordered，本身就是一个串行的状态机，很容易构造状态图。但并发算法或者分布式算法中的动作是Partially Ordered，不是一个串行的状态机，如何构造出状态图呢？如果并发算法或者分布式算法中的动作也能变成Totally Ordered，则也可以看作是一个串行的状态机，构造出状态图。实际上Lamport大师一早就研究了这个问题，在他被引用的最多的论文《Time, Clocks and the Ordering of Events in a Distributed System》中给出了为分布式系统中的事件定序的方法。简单的说就是在保证具有Partially Ordered关系的事件的顺序的前提下，将剩下的无序的事件人为定一个顺序，可以将所有事件排一个序变为Totally Ordered，并且这种定序不会破坏因果关系。事实上TLA+大放异彩的地方正是在并发算法和分布式算法领域，因为在这些领域算法的行为多种多样，容易疏漏，因此需要TLA+全面检查算法的所有路径，不漏掉任何一种行为。七 总结TLA+使用计算机强大的算力搜索算法所有可能的行为，以发现非预期的行为。随着计算机算力的提升，以及软件和硬件系统越来越复杂，TLA+将越来越受到重视，越来越成为工程师的必备技能。最后如果读者对TLA+感兴趣，这里推荐一本TLA+的入门书籍《Practical TLA+》，比较适合入门，并且网上有免费的电子版可以直接下载。MySQL高级应用 - 索引和锁MySQL 是目前最流行的关系型数据库管理系统，在 WEB 应用方面 MySQL 也是目前最好的 RDBMS 应用软件之一。本教程主要讲授针对 Java 开发所需的 MySQL 高级知识，课程中会让大家快速掌握索引，如何避免索引失效，索引的优化策略，了解innodb和myisam存储引擎，熟悉MySQL锁机制，能熟练配置MySQL主从复制，熟练掌握explain、show profile、慢查询日志等日常SQL诊断和性能分析策略。点击这里，查看详情！

开发者学堂课程【SQL进阶及查询练习：Mysql编码】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/36Mysql编码 内容简介：一 ：查看mysql数据库编码二: 编码解释三： 控制台乱码问题四： 指定默认编码   1.查看mysql数据库编码 *SHOW VARIABLES LIKE"char:2.编码解释 *character set client ：Mysql使用该编码来解读客户端发送过来的数据,例如该码为UTF8,那么如果客户端发送过来的数据不是utf8,那么就会出现乱码 *character set result:Mysql会把数据转换成该编码后,再发送给客户端,例如该编码为UTF8,那么如果客户端不使用UTF来解读,那么就会出现乱码。其它编码只要支持中文即可,也就是说不能使用latin1。3.控制台乱码问题*插入或修改时出现乱码:>这是因为cmd默认模式下使用GBK,而character set client不是GBK的原因。我们只需让这两个编码相同即可。*查询出的数据为乱码:>这是因为character set results不是GBK,而cmd默认使用GBK的原因。我们只需让这两个编码相同即可。>因为修改cmd的编码不方便,所以我们去设置character set result:为GBK即可。*设置变量的语句:>set character set clsent-gbk:> set character set clsent-gbk:注意，设置变量只对当前连接有效，当退出窗口后，再次登录mysql，还需再次设置变量。为了一劳永逸，可以在my.ini中设置：设置default-chararcter-set=gbk即可。4.   指定默认编码     我们在安装mysql 时已经指定了默认编码为utf8，所以我们在创建数据库、创建表时都无需再次制定编码。为了一劳永逸，可以在my.ini中设置：设置charaster-set-server=utf8即可。   Character set client    | ->mysql把客户端传递的数据都当成是utf8!一是他传给utf8,二是如果我们传递的是x,那么需要修改这个变量为eastes et. Datas.Character set connection |  utf8 Character set results     | utf8 -->mysql发送给客户的数据都是utf8的，一是客户用utf8编码,二是如果客户端使用gbk来码,那么需要修改这个变量为Character set serever     | utf8  Character set system     | utf8             Character setclient = utf8,,无论客户发的是什么的编码的数据,mysql都当是utf8的数据。      >若客户端发送的是GBK      >服务器会当成是utf8对待      >总结：必然乱码。处理问题的手段有两种：      >让客户端发送utf8的数据（行不通）      >把character_set_client修改为gbk       Set character_set_client =gbk；-->只有在当前窗口内有效，所以关闭窗口后再打开，又回到utf8了。Character_set_result = utf8 ,把数据用什么编码发送给客户端。     >若服务器发送给客户端的是utf8的数据     >客户端会把他当成gbk，因为小黑屏，只能显示gbk.     >总结：必然乱码。处理问题有两种手段：>让服务器发送gbk的数据>让小黑屏使用utf8来解读（行不通）My.in1  在总配置文件中进行执行，可以一劳永逸 [client] Port=3306[mysql]Default-character-set = gbk /*  它可以一劳永逸！它可以修改三个变量：       client、Result、connectio