• 关于 数据优化问题怎么解决 的搜索结果

问题

WEB开发下载服务器上面的报表怎么防止数据量过大导致超时

蛮大人123 2019-12-01 20:02:26 1425 浏览量 回答数 2

问题

【精品问答】大数据常见技术问题100问

珍宝珠 2020-02-17 13:02:59 19 浏览量 回答数 1

回答

解决应用高并发的问题方法: 第一,确认服务器硬件是否足够支持当前的流量。 普通的P4服务器一般最多能支持每天10万独立IP,如果访问量比这个还要大,那么必须首先配置一台更高性能的专用服务器才能解决问题,否则怎么优化都不可能彻底解决性能问题。 第二,优化数据库访问。 服务器的负载过大,一个重要的原因是CPU负荷过大,降低服务器CPU的负荷,才能够有效打破瓶颈。而使用静态页面可以使得CPU的负荷最小化。前台实现完全的静态化 当然最好,可以完全不用访问数据库,不过对于频繁更新的网站,静态化往往不能满足某些功能。 缓存技术 就是另一个解决方案,就是将动态数据存储到缓存文件中,动态网页直接调用这些文件,而不必再访问数据库,WordPress和Z-Blog都大量使用这种缓存技术 。我自己也写过一个Z-Blog的计数器插件,也是基于这样的原理。 如果确实无法避免对数据库的访问,那么可以尝试优化数据库的查询SQL.避免使用Select *from这样的语句,每次查询只返回自己需要的结果,避免短时间内的大量SQL查询。 来源于网络,供您参考

保持可爱mmm 2019-12-02 02:20:12 0 浏览量 回答数 0

新用户福利专场,云服务器ECS低至102元/年

新用户专场,1核2G 102元/年起,2核4G 699.8元/年起

问题

MySQL专家丁奇社区问答集锦

管理贝贝 2019-12-01 20:17:59 3686 浏览量 回答数 7

问题

请教大神关于foreach 嵌套循环,性能优化的问题

落地花开啦 2019-12-01 19:58:39 1398 浏览量 回答数 1

问题

如何解决内地访问香港主机经常无法访问问题

1864286169765109 2020-07-13 14:08:16 26 浏览量 回答数 1

回答

" 用了两年的时间,终于把这个问题解决了。。######能分享下如何解决的吗###### 分布式事务的基本理论,2PC, QUORUM, PAXOS,系统要达到100w/s的水准靠水平分割 ######好问题,。。。######mark######你的解法是正确可行的,不知道面试官是怎么想的,估计面试官自己都没有答案。 消息队列是可以集群的,最终的瓶颈只是在数据库上面,所以要做多master应该就可以解决了。 如果单库多master还无法解决的话,那就要进行数据库分割。 如果分割了还无法解决的话,那就要采用内存数据库,然后在持久化到磁盘。 灵活运用吧。 ###### 两阶段提交本身属于强一致性模型,你又说做最终一致检查,有点概念不清的嫌疑。 所以面试官在听到你说2PC的时候,估计已经不想跟你扯了, 猜测~~。    其实海量分布式事务的解决方案就是最终一致性模型。 ######因为他的说法中有错别字,我没有看到2pc,这一点他的强一致模型确实和最终一致模型概念不清。楼主本身估计不是做架构的,是根据自己公司原来的架构体系自己总结的一些东西。不过楼主的解决方案的大体方向是可行的。###### 引用来自“jobet”的评论你的解法是正确可行的,不知道面试官是怎么想的,估计面试官自己都没有答案。 消息队列是可以集群的,最终的瓶颈只是在数据库上面,所以要做多master应该就可以解决了。 如果单库多master还无法解决的话,那就要进行数据库分割。 如果分割了还无法解决的话,那就要采用内存数据库,然后在持久化到磁盘。 灵活运用吧。 什么东西一大了,单纯靠数据库,分布式平台等数据工具是解决不了的。一定要结合具体业务特性,大概率下数据分布特征来做模型的重新设计和优化。这就是我说的,大数据的工作,hadoop之类的工具,并不能帮你做什么。还是自身业务模型设计的问题。哈######其实这个问题基本上没有正确的方案,每一个平台根据业务性质都会不同,唯一能够提供的就是一个大体的思虑,其他的根据自己的业务性质自行提炼和优化。###### 引用来自“兮风古道”的评论 两阶段提交本身属于强一致性模型,你又说做最终一致检查,有点概念不清的嫌疑。 所以面试官在听到你说2PC的时候,估计已经不想跟你扯了, 猜测~~。    其实海量分布式事务的解决方案就是最终一致性模型。 二段提交的时候,最后一次commit还是会出错的。。######回复 @jobet : 收到。。我搞错了。。######回复 @Brin想写程序 : 2pc是针对于多数据源的事务处理,也就是分布式事务。你说的这个不是。######回复 @jobet : 问一下mysql的autocommit=false后的,commit和rollback难道不是二段提交的吗?这个应该就是数据库的二段提交吧?######2pc的话,对性能的消耗是很大的。估计面试官是因为听到他说2pc就直接否决了,后续的已经没有兴趣了。###### Brin有什么好办法了,记得 博客里补上######我的解决方案是根据用户顺序处理,也就是用顺序一致性替代绝对一致性,然后用分布式消息队列,用一致性哈希算法,只将一个用户的数据发送给同一个处理者,然后按顺序执行这一个人的操作。所以这个是无锁的,可并行的。###### 引用来自“jobet”的评论你的解法是正确可行的,不知道面试官是怎么想的,估计面试官自己都没有答案。 消息队列是可以集群的,最终的瓶颈只是在数据库上面,所以要做多master应该就可以解决了。 如果单库多master还无法解决的话,那就要进行数据库分割。 如果分割了还无法解决的话,那就要采用内存数据库,然后在持久化到磁盘。 灵活运用吧。 引用来自“中山野鬼”的评论什么东西一大了,单纯靠数据库,分布式平台等数据工具是解决不了的。一定要结合具体业务特性,大概率下数据分布特征来做模型的重新设计和优化。这就是我说的,大数据的工作,hadoop之类的工具,并不能帮你做什么。还是自身业务模型设计的问题。哈 我也觉得是具体业务具体分析,比如在电商平台里面,在怎么分布式,买东西这个过程是一个用户触发的。 所以按照用户对纬度,对资源进行水平分割,应该可以解决大部分问题。 但是但是,最麻烦的是先有很多电商平台非常庞大,而且一开始就没有做这种分割,业务是一团乱麻,没人清楚这个用户的购买行为会影响多少台服务器里面的数据,所以只能寻找比较通用的解决方案。 也就是在某个层面上能彻底解决,现在好像思路还是从rpc层面去解决这个问题。找到统一的一劳永逸的中间价或者说体系结构。。 所以我也很难想明白。。######马克,学习了"

kun坤 2020-05-26 13:15:05 0 浏览量 回答数 0

问题

程序员报错迷惑行为大赏-python报错

问问小秘 2020-06-11 11:48:32 43 浏览量 回答数 2

问题

【精品问答】云数据库十大经典案例总结和反思

问问小秘 2020-01-02 13:09:08 8 浏览量 回答数 1

问题

云端数据库的查询方法是什么样子的

虾米--- 2019-12-01 19:40:47 884 浏览量 回答数 4

问题

SQL Server优化案例分享【精品问答集锦】

管理贝贝 2019-12-01 19:26:00 41377 浏览量 回答数 35

问题

【教程免费下载】Redis开发与运维

知与谁同 2019-12-01 22:07:46 2741 浏览量 回答数 2

回答

Re阿里云主机从6号起CPU一直99%,不知道怎么回事? 淘宝不行,找了好几个 解决不了问题 已经搞定了,找了版主服务器之家搞定了。数据库问题,优化了一下好了

pangchangfei 2019-12-02 00:02:25 0 浏览量 回答数 0

回答

Java架构师,首先要是一个高级java攻城狮,熟练使用各种框架,并知道它们实现的原理。jvm虚拟机原理、调优,懂得jvm能让你写出性能更好的代码;池技术,什么对象池,连接池,线程池……    Java反射技术,写框架必备的技术,但是有严重的性能问题,替代方案java字节码技术;nio,没什么好说的,值得注意的是”直接内存”的特点,使用场景;java多线程同步异步;java各种集合对象的实现原理,了解这些可以让你在解决问题时选择合适的数据结构,高效的解决问题,比如hashmap的实现原理,好多五年以上经验的人都弄不清楚,还有为什扩容时有性能问题?不弄清楚这些原理,就写不出高效的代码,还会认为自己做的很对;总之一句话越基础的东西越重要,很多人认为自己会用它们写代码了,其实仅仅是知道如何调用api而已,离会用还差的远。    熟练使用各种数据结构和算法,数组、哈希、链表、排序树…,一句话要么是时间换空间要么是空间换时间,这里展开可以说一大堆,需要有一定的应用经验,用于解决各种性能或业务上的问题。    熟练使用linux操作系统,必备,没什么好说的 。    熟悉tcp协议,创建连接三次握手和断开连接四次握手的整个过程,不了解的话,无法对高并发网络应用做优化; 熟悉http协议,尤其是http头,我发现好多工作五年以上的都弄不清session和cookie的生命周期以及它们之间的关联。    系统集群、负载均衡、反向代理、动静分离,网站静态化 。    分布式存储系统nfs,fastdfs,tfs,Hadoop了解他们的优缺点,适用场景 。    分布式缓存技术memcached,redis,提高系统性能必备,一句话,把硬盘上的内容放到内存里来提速,顺便提个算法一致性hash 。    工具nginx必备技能超级好用,高性能,基本不会挂掉的服务器,功能多多,解决各种问题。    数据库的设计能力,mysql必备,最基础的数据库工具,免费好用,对它基本的参数优化,慢查询日志分析,主从复制的配置,至少要成为半个mysql dba。其他nosql数据库如mongodb。    还有队列中间件。如消息推送,可以先把消息写入数据库,推送放队列服务器上,由推送服务器去队列获取处理,这样就可以将消息放数据库和队列里后直接给用户反馈,推送过程则由推送服务器和队列服务器完成,好处异步处理、缓解服务器压力,解藕系统。   以上纯粹是常用的技术,还有很多自己慢慢去摸索吧;因为要知道的东西很多,所以要成为一名合格的架构师,必须要有强大的自学能力,没有人会手把手的教给你所有的东西。    想成为架构师不是懂了一大堆技术就可以了,这些是解决问题的基础、是工具,不懂这些怎么去提解决方案呢?这是成为架构师的必要条件。    架构师要针对业务特点、系统的性能要求提出能解决问题成本最低的设计方案才合格,人家一个几百人用户的系统,访问量不大,数据量小,你给人家上集群、上分布式存储、上高端服务器,为了架构而架构,这是最扯淡的,架构师的作用就是第一满足业务需求,第二最低的硬件网络成本和技术维护成本。    架构师还要根据业务发展阶段,提前预见发展到下一个阶段系统架构的解决方案,并且设计当前架构时将架构的升级扩展考虑进去,做到易于升级;否则等系统瓶颈来了,出问题了再去出方案,或现有架构无法扩展直接扔掉重做,或扩展麻烦问题一大堆,这会对企业造成损失。Java架构师学习路线图如:https://yq.aliyun.com/articles/225941?spm=5176.8091938.0.0.qyp0tC

zwt9000 2019-12-02 00:25:32 0 浏览量 回答数 0

问题

X亿级数据检索速度优化难题

吴孟桥 2019-12-01 19:52:15 1195 浏览量 回答数 1

回答

ReMySQL官方管理工具上线啦,快来体验! 用RDS的初衷是省心,不需要自己维护mysql数据库,其实看到RDS控制面板里有优化的一些监控选项,但是我想说的是如果RDS控制面板也好,IDB也罢,如果只停留在(更多RDS数据库性能优化相关的数据,便于开发人员、SA、DBA优化数据库。)那依然是把RDS当作给程序员,开发人员,大公司(有能力雇开发人员)用的,而不是给普通站长用的. 希望能站在普通站长的角度,看看能不能有更加方便的工具,提示,或者引导,指导,普通站长(没开发能力的)去优化RDS数据库呢? 我虽然很喜欢阿里云的产品,包括ECS,RDS,OSS等等,但是这些产品说实话都是停留在面向于有开发能力,有windows,liunx服务器环境实施操作能力的站长,不过相对于其他产品而言ECS的第三方工具以及第三方合作伙伴生态环境相对来说好很多,教程也比较多,如果遇到虽然不懂怎么操作,但是善于学习的站长来说还是可以的,RDS导入数据库应该说也勉强能够接受,但是RDS的优化我反正是看不懂了,当然也不敢轻易的去动设置选项,也没钱找开发人员,或者数据库维护人员帮我优化了! OSS就更惨了,找不到合适的discuz x3.1插件不说,连几十G数据想从upyun搬家到青岛oss节点,都找不到合适的解决方案. ------------------------- ReMySQL官方管理工具上线啦,快来体验! 貌似查询数量只能3000条,但是如果我想修改超过3000条以上的数据怎么办? ------------------------- 回12楼钟隐的帖子 以前一直是用phpmyadmin来管理mysql数据库的,既然你们让我们的phpmyadmin say NO,那你们得给我们一个理由让我们去say NO,假设phpmyadmin能做到的事情你们无法做到,我们又为什么要去对phpmyadmin say NO,您也给我一个理由! 不要说想像不出来什么场景,既然一个事物要代替另一个事物,你必须要满足建立在拥有代替那个事物全部功能基础之上的,也就是说他能做到的,你们都能做到,他做不到的你们还能做到,不然用户为什么要对原来的事物say no? 开发人员可能无法站在普通站长的视角去看问题,因为我们无法站长开发人员的视角去处理问题,因为我们是普通站长,我们不懂SQL语句 我是不敢轻易在phpmyadmin里运行SQL语句的,万一错了,导致后果很严重,我们菜鸟就真的束手无策了,我也不敢说很懂phpmyadmin如何使用,至少我从来没用过,我看一下,我能简单的对我的数据库里的内容进行修改! 我用的是discuz,在phpmyadmin里左侧可以看到各种discuz数据库里的表单,比如记录帖子的表单,比如记录用户的表单,我在phpmyadmin里是可以把某一个帖子的数据调出来修改的! 比如这个帖子的数据是在第9000多个,我虽然你不懂语句,我可以在phpmyadmin里查看第多少页到多少页的数据,我让他一页显示多少个,然后再估算一下多少页之间可以找到这帖子的数据,我就能找到这个帖子的数据,然后对这个数据进行修改! 可是在你们的这个工具里,我只能查看到3000条,可是3000条之后的呢?我不是说要一次性查看几万条,几十万条,可是如果数据如果是有编号的从1-50万,如果我要查看这50万条数据中最后的3000条我要如何做? 其实你们错误的理解我们的需求,你认为我们是要批量修改超过3000条的数据,其实是我在查看一个表的时候这个表有几十万条数据,问题是我无法做到查看排序在3000条以后的数据.....,看来看去就只能看到前3000条,问题是我要改后面的数据 您看一下用户的反馈都是对翻页功能,查询数据的功能吐槽! 我想他的问题应该跟我一样,想通过翻页,查询找到自己想要的数据是很痛苦的! 最倒霉的是把phpmyadmin里这些功能给限制不让用了!

solidedge 2019-12-01 23:27:53 0 浏览量 回答数 0

回答

ReMySQL官方管理工具上线啦,快来体验! 用RDS的初衷是省心,不需要自己维护mysql数据库,其实看到RDS控制面板里有优化的一些监控选项,但是我想说的是如果RDS控制面板也好,IDB也罢,如果只停留在(更多RDS数据库性能优化相关的数据,便于开发人员、SA、DBA优化数据库。)那依然是把RDS当作给程序员,开发人员,大公司(有能力雇开发人员)用的,而不是给普通站长用的. 希望能站在普通站长的角度,看看能不能有更加方便的工具,提示,或者引导,指导,普通站长(没开发能力的)去优化RDS数据库呢? 我虽然很喜欢阿里云的产品,包括ECS,RDS,OSS等等,但是这些产品说实话都是停留在面向于有开发能力,有windows,liunx服务器环境实施操作能力的站长,不过相对于其他产品而言ECS的第三方工具以及第三方合作伙伴生态环境相对来说好很多,教程也比较多,如果遇到虽然不懂怎么操作,但是善于学习的站长来说还是可以的,RDS导入数据库应该说也勉强能够接受,但是RDS的优化我反正是看不懂了,当然也不敢轻易的去动设置选项,也没钱找开发人员,或者数据库维护人员帮我优化了! OSS就更惨了,找不到合适的discuz x3.1插件不说,连几十G数据想从upyun搬家到青岛oss节点,都找不到合适的解决方案. ------------------------- ReMySQL官方管理工具上线啦,快来体验! 貌似查询数量只能3000条,但是如果我想修改超过3000条以上的数据怎么办? ------------------------- 回12楼钟隐的帖子 以前一直是用phpmyadmin来管理mysql数据库的,既然你们让我们的phpmyadmin say NO,那你们得给我们一个理由让我们去say NO,假设phpmyadmin能做到的事情你们无法做到,我们又为什么要去对phpmyadmin say NO,您也给我一个理由! 不要说想像不出来什么场景,既然一个事物要代替另一个事物,你必须要满足建立在拥有代替那个事物全部功能基础之上的,也就是说他能做到的,你们都能做到,他做不到的你们还能做到,不然用户为什么要对原来的事物say no? 开发人员可能无法站在普通站长的视角去看问题,因为我们无法站长开发人员的视角去处理问题,因为我们是普通站长,我们不懂SQL语句 我是不敢轻易在phpmyadmin里运行SQL语句的,万一错了,导致后果很严重,我们菜鸟就真的束手无策了,我也不敢说很懂phpmyadmin如何使用,至少我从来没用过,我看一下,我能简单的对我的数据库里的内容进行修改! 我用的是discuz,在phpmyadmin里左侧可以看到各种discuz数据库里的表单,比如记录帖子的表单,比如记录用户的表单,我在phpmyadmin里是可以把某一个帖子的数据调出来修改的! 比如这个帖子的数据是在第9000多个,我虽然你不懂语句,我可以在phpmyadmin里查看第多少页到多少页的数据,我让他一页显示多少个,然后再估算一下多少页之间可以找到这帖子的数据,我就能找到这个帖子的数据,然后对这个数据进行修改! 可是在你们的这个工具里,我只能查看到3000条,可是3000条之后的呢?我不是说要一次性查看几万条,几十万条,可是如果数据如果是有编号的从1-50万,如果我要查看这50万条数据中最后的3000条我要如何做? 其实你们错误的理解我们的需求,你认为我们是要批量修改超过3000条的数据,其实是我在查看一个表的时候这个表有几十万条数据,问题是我无法做到查看排序在3000条以后的数据.....,看来看去就只能看到前3000条,问题是我要改后面的数据 您看一下用户的反馈都是对翻页功能,查询数据的功能吐槽! 我想他的问题应该跟我一样,想通过翻页,查询找到自己想要的数据是很痛苦的! 最倒霉的是把phpmyadmin里这些功能给限制不让用了!

solidedge 2019-12-02 02:57:39 0 浏览量 回答数 0

问题

ISV开发中遇见的两个棘手问题。

天下之中人 2019-12-01 21:03:19 4682 浏览量 回答数 3

回答

建议考虑下NoSql数据库和Map/Reduce架构(如Hadoop)######放在数据库里面###### 一个用户有上亿条数据? 还是在上亿条里面有所有用户。 ######就是解决大数据在java中的计算,及内存开销问题######分布式集群、搜索引擎和nosql ###### 对于这种上网日志行为的数据。如果把所有用户的数据放到同一个表格同一个数据库里面,说明设计上就有问题。 这种历史数据,完全可以采用分库分表策略(按用户的ID进行分库分表) ######换php######你确定 这样可以?######他说有1一条日志,不是1亿访问量,用个算法处理一下,再分文件存储 [0]###### 应该分层处理以及避免过早优化, 程序该怎么写就怎么写。 数据库自动cache或者加面对开发透明的cache,诸如mc/redis,适当修改逻辑,提高命中率就好。 不过要考虑网络传输成本,或者多几个节点来分流预热数据,尽量减少网络和磁盘开销。Java数据读取:http://edu.51cto.com/course/course_id-3283.html

kun坤 2020-06-06 23:14:47 0 浏览量 回答数 0

回答

但是我怎么知道查询没错呢?测试更新和删除-与测试插入内容相同**---编写数据对比插件** 它会在用于输出查询的别名中附加一些命名疣**---你考虑的方向错了,应该是从数据注入开始想,另外你如果是希望通过SQL去解决你现在的问题,可以进行数据双重\多重验证** 我应该放弃所有内容,只是信任NHibernate吗?---实际证明优化工作逻辑是一个很大的难点,我的意见是只做参考,而不能够全信

测开小子 2020-01-03 14:40:23 0 浏览量 回答数 0

问题

基于大数据的全球电商系统架构性能优化【精品问答集锦】

管理贝贝 2019-12-01 20:28:14 29317 浏览量 回答数 13

回答

ReiDBCloud导出的数据库在本地win下的mysql中怎么导入都有错误 能否把导入报错信息发出来,一起看看原因? 如果要自行排查,可以从以下几点着手: 1.导出内容主要分为表结构、表数据、数据库对象,对应在iDB Cloud导出功能上有选项|高级选项来选择是否导出的,可以先测试下仅仅导出结构和数据,但不导出数据库其他对象 2.导出文件中都会在开始加上SET FOREIGN_KEY_CHECKS = 0; 防止外键对导入的影响,DROP TABLE IF EXISTS  `test1`;用来防止导入数据库同名表的影响 3.剩下的可能点就是权限了,请查看下是否有权限不足的报错 展开一下: 从产品上考虑,导出操作除了生成文件外,再生成一个导入预检查脚本,如果在iDB Cloud上导入就可以直接识别导入文件和预检查脚本,将可能导致导入失败的问题点、解决方案、甚至一键优化给到用户,如果操作发生在用户本地MySQL,用户单独使用导入预检查脚本也能得知可能导致导入失败的问题点和解决建议,回头我再仔细评估下这个方案!

佩恩六道 2019-12-02 01:44:35 0 浏览量 回答数 0

问题

RDS查询速度奇慢

arker 2019-12-01 21:11:37 14089 浏览量 回答数 5

回答

希望楼主能多分享下优化心得哈 ######心得?就是怀疑一切。我相信在Soc公司里,开发driver,特别是网络,电源管理,总线方面的朋友都知道。spec有时只能当草纸用。 ######反汇编下代码,看看编译结果有无问题.######去掉编译优化选项再试试######会不会跟子函数传递形参有关?###### 你用的是什么编译器? gcc for arm?你这个问题很可能是编译器的问题. gcc不可靠的对容易有歧义和很复杂的表达式,编译出来的东西是错误的.以前遇到过. VC的或者商用编译器就好多了. ######这么说,反汇编已经检查过了吧,如果确定汇编也没有问题的话,那就只能是硬件层的了。 编译器一般情况下是不会犯错的,因为它无论怎么优化,第一个原则就是正确性,在原程序中会被执行的代码在结果里也一定会被执行。然而,对于不同的芯片,实现上可能会有一定的差异,对编译器也有不同程度的裁剪,但它毕竟只是个程序。再者,芯片实现越来越复杂,内部指令到底是个怎么执行流程,连代码自己都不能知道,何况是编译器和程序员。###### 引用来自“ZeroOne”的答案 你用的是什么编译器? gcc for arm?你这个问题很可能是编译器的问题. gcc不可靠的对容易有歧义和很复杂的表达式,编译出来的东西是错误的.以前遇到过. VC的或者商用编译器就好多了. 上ARM 1GHz的Soc跑的准“固件”。我没办法用VC。而且是android 的NDK。 ###### 引用来自“晓寒”的答案 这么说,反汇编已经检查过了吧,如果确定汇编也没有问题的话,那就只能是硬件层的了。 编译器一般情况下是不会犯错的,因为它无论怎么优化,第一个原则就是正确性,在原程序中会被执行的代码在结果里也一定会被执行。然而,对于不同的芯片,实现上可能会有一定的差异,对编译器也有不同程度的裁剪,但它毕竟只是个程序。再者,芯片实现越来越复杂,内部指令到底是个怎么执行流程,连代码自己都不能知道,何况是编译器和程序员。 目前怀疑是函数过早跳出,对应寄存器的值没有有效传递给外部变量前,被堆栈弹出的数据覆盖,转而将数据写出变量时导致错误。虽然问题解决了。但是具体原因我还需要查一下。当然可能有另外个错误,就是进入计算和判断的变量,在寄存器传递为有些写入前,就被使用。 ######这个问题目前查清楚了,让小朋友看反汇编,让他自己理解。还不错。把问题向我汇报清楚了 。也希望大家注意, android下的C编译器存在错误。尽量把C代码写简单点。上述错误是C编译器在优化模式下的逻辑错误。

kun坤 2020-05-30 14:00:18 0 浏览量 回答数 0

回答

ReCentOS64位的是不是比32位的浪费资源,重启没多久就连接不上数据库了。 重启没多久又连接不上数据库,会不会是占有内存太多,有优化方法吗? ------------------------- Re回5楼lijinhao的帖子 引用第6楼云迷于2013-04-09 11:45发表的 回5楼lijinhao的帖子 : 你图片多不多,我用阿里云官方提供“成本核算器”,他们是按网站类型和ip量等因素给出配置建议的,我试了无论是哪种网站类型,他们多数情况下都建议先升级内存,而不是宽带,您可以跟据你自己的情况测下: http://www.aliyun.com/promotion/bijia?spm=5176.383518.0.56.YtvSzJ   完了说说结果吧! 关键是现在我网站才上线,一天不到10IP。 ------------------------- Re回7楼lijinhao的帖子 引用第8楼云迷于2013-04-09 12:39发表的 回7楼lijinhao的帖子 : 建议你提交工单说明下!他们应该会给你一个合理的解决方案 谢谢朋友提醒,提交过,他们让我优化数据库,不懂这些,所以问问有没有人遇到过相同的问题,如何解决的? ------------------------- Re回9楼lijinhao的帖子 引用第10楼云迷于2013-04-09 13:35发表的 回9楼lijinhao的帖子 : 继续提交,问他们优化数据库具体怎么操作! 这也行。

lijinhao 2019-12-02 00:58:05 0 浏览量 回答数 0

回答

回 2楼(zc_0101) 的帖子 您好,       您的问题非常好,SQL SERVER提供了很多关于I/O压力的性能计数器,请选择性能计算器PhysicalDisk(LogicalDisk),根据我们的经验,如下指标的阈值可以帮助你判断IO是否存在压力: 1.  % Disk Time :这个是磁盘时间百分比,这个平均值应该在85%以下 2.  Current Disk Queue Length:未完成磁盘请求数量,这个每个磁盘平均值应该小于2. 3.  Avg. Disk Queue Length:磁盘请求队列的平均长度,这个每个磁盘平均值也应该小于2 4.  Disk Transfers/sec:每次磁盘传输数量,这个每个磁盘的最大值应该小于100 5.  Disk Bytes/sec:每次磁盘传入字节数,这个在普通的磁盘上应该在10M左右 6.  Avg. Disk Sec/Read:从磁盘读取的平均时间,这个平均值应该小于10ms(毫秒) 7.  Avg. Disk Sec/Write:磁盘写入的平均时间,这个平均值也应该小于10ms(毫秒) 以上,请根据自己的磁盘系统判断,比如传统的机械臂磁盘和SSD有所不同。 一般磁盘的优化方向是: 1. 硬件优化:比如使用更合理的RAID阵列,使用更快的磁盘驱动器,添加更多的内存 2. 数据库设置优化:比如创建多个文件和文件组,表的INDEX和数据放到不同的DISK上,将数据库的日志放到单独的物理驱动器,使用分区表 3. 数据库应用优化:包括应用程序的设计,SQL语句的调整,表的设计的合理性,INDEX创建的合理性,涉及的范围很广 希望对您有所帮助,谢谢! ------------------------- 回 3楼(鹰舞) 的帖子 您好,      根据您的描述,由于查询产生了副本REDO LOG延迟,出现了架构锁。我们知道SQL SERVER 2012 AlwaysOn在某些数据库行为上有较多变化。我们先看看架构锁: 架构锁分成两类: 1. SCH-M:架构更改锁,主要发生在数据库SCHEMA的修改上,从你的描述看,没有更改SCHEMA,那么可以排除这个因素 2. SCH-S:架构稳定锁,主要发生在数据库的查询编译等活动 根据你的情况,应该属于SCH-S导致的。查询编译活动主要发生有新增加了INDEX, 更新了统计信息,未参数化的SQL语句等等 对于INDEX和SQL语句方面应,我想应该不会有太多问题。 我们重点关注一下统计信息:SQL SERVER 2012 AG副本的统计信息维护有两种: 1. 主体下发到副本 2. 临时统计信息存储在TEMPDB 对于主体下发的,我们可以设置统计信息的更新行为,自动更新时,可以设置为异步的(自动更新统计信息必须首先打开): USE [master] GO ALTER DATABASE [Test_01]     SET AUTO_UPDATE_STATISTICS_ASYNC ON WITH NO_WAIT GO 这样的话查询优化器不等待统计信息更新完成即编译查询。可以优化一下你的BLOCK。 对于临时统计信息存储在TEMPDB里面也是很重要的,再加上ALWAYSON的副本数据库默认是快照隔离,优化TEMPDB也是必要的,关于优化TEPDB这个我想大部分都知道,这里只是提醒一下。 除了从统计信息本身来解决,在查询过程中,可以降低查询的时间,以尽量减少LOCK的时间和范围,这需要优化你的SQL语句或者应用程序。 以上,希望对您有所帮助。谢谢! ------------------------- 回 4楼(leamonjxl) 的帖子 这是一个关于死锁的问题,为了能够提供帮助一些。请根据下列建议进行: 1.    跟踪死锁 2.    分析死锁链和原因 3.    一些解决办法 关于跟踪死锁,我们首先需要打开1222标记,例如DBCC TRACEON(1222,-1), 他将收集的信息写入到死锁事件发生的服务器上的日志文件中。同时建议打开Profiler的跟踪信息: 如果发生了死锁,需要分析死锁发生的根源在哪里?我们不是很清楚你的具体发生死锁的形态是怎么样的。 关于死锁的实例也多,这里不再举例。 这里只是提出一些可以解决的思路: 1.    减少锁的争用 2.    减少资源的访问数 3.    按照相同的时间顺序访问资源 减少锁的争用,可以从几个方面入手 1.    使用锁提示,比如为查询语句添加WITH (NOLOCK), 但这还取决于你的应用是否允许,大部分分布式的系统都是可以加WITH (NOLOCK), 金融行业可能需要慎重。 2.    调整隔离级别,使用MVCC,我们的数据库默认级别是READ COMMITED. 建议修改为读提交快照隔离级别,这样的话可以尽量读写不阻塞,只不过MVCC的ROW VERSION保存到TEMPDB下面,需要维护好TEMPDB。当然如果你的整个数据库隔离级别可以设置为READUNCOMMINTED,这些就不必了。 减少资源的访问数,可以从如下几个方面入手: 1.    使用聚集索引,非聚集INDEX的叶子页面与堆或者聚集INDEX的数据页面分离。因此,如果对非聚集INDEX 操作的话,会产生两个锁,一个是基本表,一个是非聚集INDEX。而聚集INDEX就不一样,聚集INDEX的叶子页面和表的数据页面相同,他只需要一个LOCK。 2.    查询语句尽量使用覆盖INDEX, 使用全覆盖INDEX,就不需要访问基本表。如果没有全覆盖,还会通过RID或者CLUSTER INDEX访问基本表,这样产生的LOCK可能会与其他SESSION争用。 按照相同的时间顺序访问资源: 确保每个事务按照相同的物理顺序访问资源。两个事务按照相同的物理顺序访问,第一个事务会获得资源上的锁而不会被第二个事务阻塞。第二个事务想获得第一个事务上的LOCK,但被第一个事务阻塞。这样的话就不会导致循环阻塞的情况。 ------------------------- 回 4楼(leamonjxl) 的帖子 两种方式看你的业务怎么应用。这里不仅是分表的问题,还可能存在分库,分服务器的问题。取决与你的架构方案。 物理分表+视图,这是一种典型的冷热数据分离的方案,大致的做法如下: 1.    保留最近3个月的数据为当前表,也即就是我们说的热数据 2.    将其他数据按照某种规则分表,比如按照年或者季度或者月,这部分是相对冷的数据 分表后,涉及到几个问题: 第一问题是,转移数据的过程,一般是晚上业务比较闲来转移,转移按照一定的规则来做,始终保持3个月,这个定时任务本身也很消耗时间 再者,关于查询部分,我想你们的数据库服务器应该通过REPLICATION做了读写分离的吧,主库我觉得压力不会太大,主要是插入或者更新,只读需要做视图来包含全部的数据,但通过UNION ALL所有分表的数据,最后可能还是非常大,在某些情况下,性能不一定好。这个是不是业务上可以解决。比如,对于1年前的历史数据,放在单独的只读上,相对热的数据放在一起,这样压力也会减少。 分区表的话,因为涉及到10亿数据,要有好的分区方案,相对比较简单一点。但对于10亿的大表,始终是个棘手的问题,无论分多少个分区,单个服务器的资源也是有限的。可扩展性方面也存在问题,比如在只读上你没有办法做服务器级别的拆分了。这可能也会造成瓶颈。 现在很多企业都在做分库分表,这些的要解决一些高并发,数据量大的问题。不知是否考虑过类似于中间件的方案,比如阿里巴巴的TDDL类似的方案,如果你有兴趣,可以查询相关资料。 ------------------------- 回 9楼(jiangnii) 的帖子 阿里云数据库不仅提供一个数据库,还提供数据库一种服务。阿里云数据库不仅简化了基础架构的部署,还提供了数据库高可用性架构,备份服务,性能诊断服务,监控服务,专家服务等等,保证用户放心、方便、省心地使用数据库,就像水电一样。以前的运维繁琐的事,全部由阿里云接管,用户只需要关注数据库的使用和具体的业务就好。 关于优化和在云数据库上处理大数据量或复杂的数据操作方面,在云数据库上是一样的,没有什么特别的地方,不过我们的云数据库是使用SSD磁盘,这个比普通的磁盘要快很多,IO上有很大的优势。目前单个实例支持1T的数据量大小。陆续我们会推出更多的服务,比如索引诊断,连接诊断,容量分析,空间诊断等等,这些工作可能是专业的DBA才能完成的,以后我们会提供自动化的服务来为客户创造价值,希望能帮助到客户。 谢谢! ------------------------- 回 12楼(daniellin17) 的帖子 这个问题我不知道是否是两个问题,一个是并行度,另一个是并发,我更多理解是吞吐量,单就并行度而言。 提高并行度需要考虑的因素有: 1.    可用于SQL SERVER的CPU数量 2.    SQL SERVER的版本(32位/64位) 3.    可用内存 4.    执行的查询类型 5.    给定的流中处理的行数 6.    活动的并发连接数量 7.    sys.configurations参数:affinity mask/max server memory (MB)/ max degree of parallelism/ cost threshold for parallelism 以DOP的参数控制并行度为例,设置如下: SELECT * FROM sys.configurations WITH (NOLOCK) WHERE name = 'max degree of parallelism' EXEC sp_configure 'max degree of parallelism',2 RECONFIGURE WITH OVERRIDE 经过测试,DOP设置为2是一个比较适中的状态,特别是OLTP应用。如果设置高了,会产生较多的SUSPEND进程。我们可以观察到资源等待资源类型是:CXPACKET 你可以用下列语句去测试: DBCC SQLPERF('sys.dm_os_wait_stats',CLEAR) SELECT * FROM sys.dm_os_wait_stats WITH (NOLOCK) ORDER BY 2 DESC ,3 DESC 如果是吞吐量的话。优化的范围就很广了。优化是系统性的。硬件配置我们选择的话,大多根据业务量来预估,然后考虑以下: 1.    RAID的划分,RAID1适合存放事务日志文件(顺序写),RAID10/RAID5适合做数据盘,RAID10是条带化并镜像,RAID5条带化并奇偶校验 2.    数据库设置,比如并行度,连接数,BUFFER POOL 3.    数据库文件和日志文件的存放规则,数据库文件的多文件设置规则 4.    TEMPDB的优化原则,这个很重要的 5.    表的设计方面根据业务类型而定 6.    CLUSTERED INDEX和NONCLUSTERED INDEX的设计 7.    阻塞分析 8.    锁和死锁分析 9.    执行计划缓冲分析 10.    存储过程重编译 11.    碎片分析 12.    查询性能分析,这个有很多可以优化的方式,比如OR/UNION/类型转换/列上使用函数等等 我这里列举一个高并发的场景: 比如,我们的订单,比如搞活动的时候,订单刷刷刷地增长,单个实例可能每秒达到很高很高,我们分析到最后最常见的问题是HOT PAGE问题,其等待类型是PAGE LATCH竞争。这个过程可以这么来处理,简单列几点,可以参考很多涉及高并发的案例: 1.    数据库文件和日志文件分开,存放在不同的物理驱动器磁盘上 2.    数据库文件需要与CPU个数形成一定的比例 3.    表设计可以使用HASH来作为表分区 4.    表可以设置无序的KEY/INDEX,比如使用GUID/HASH VALUE来定义PRIMARY KEY CLUSTER INDEX 5.    我们不能将自增列设计为聚集INDEX 这个场景只是针对高并发的插入。对于查询而言,是不适合的。但这些也可能导致大量的页拆分。只是在不同的场景有不同的设计思路。这里抛砖引玉。 ------------------------- 回 13楼(zuijh) 的帖子 ECS上现在有两种磁盘,一种是传统的机械臂磁盘,另一种是SSD,请先诊断你的IO是否出现了问题,本帖中有提到如何判断磁盘出现问题的相关话题,请参考。如果确定IO出现问题,可以尝试使用ECS LOCAL SSD。当然,我们欢迎你使用云数据库的产品,云数据库提供了很多有用的功能,比如高可用性,灵活的备份方案,灵活的弹性方案,实用的监控报警等等。 ------------------------- 回 17楼(豪杰本疯子) 的帖子 我们单个主机或者单个实例的资源总是有限的,因为涉及到很大的数据量,对于存储而言是个瓶颈,我曾使用过SAN和SAS存储,SAN存储的优势确实可以解决数据的灵活扩展,但是SAN也分IPSAN和FIBER SAN,如果IPSAN的话,性能会差一些。即使是FIBER SAN,也不是很好解决性能问题,这不是它的优势,同时,我们所有DB SERVER都连接到SAN上,如果SAN有问题,问题涉及的面就很广。但是SAS毕竟空间也是有限的。最终也会到瓶颈。数据量大,是造成性能问题的直接原因,因为我们不管怎么优化,一旦数据量太大,优化的能力总是有限的,所以这个时候更多从架构上考虑。单个主机单个实例肯定是抗不过来的。 所以现在很多企业在向分布式系统发展,对于数据库而言,其实有很多形式。我们最常见的是读写分离,比如SQL SERVER而言,我们可以通过复制来完成读写分离,SQL SERVER 2012及以后的版本,我们可以使用ALWAYSON来实现读写分离,但这只能解决性能问题,那空间问题怎么解决。我们就涉及到分库分表,这个分库分表跟应用结合得紧密,现在很多公司通过中间件来实现,比如TDDL。但是中间件不是每个公司都可以玩得转的。因此可以将业务垂直拆分,那么DB也可以由此拆分开来。举个简单例子,我们一个典型的电子商务系统,有订单,有促销,有仓库,有配送,有财务,有秒杀,有商品等等,很多公司在初期,都是将这些放在一个主机一个实例上。但是这些到了一定规模或者一定数据量后,就会出现性能和硬件资源问题,这时我们可以将它们独立一部分获完全独立出来。这些都是一些好的方向。希望对你有所帮助。 ------------------------- 回 21楼(dt) 的帖子 问: 求大数据量下mysql存储,优化方案 分区好还是分表好,分的过程中需要考虑事项 mysql高并发读写的一些解决办法 答: 分区:对于应用来说比较简单,改造较少 分表: 应用需较多改造,优点是数据量太大的情况下,分表可以拆分到多个实例上,而分区不可以。 高并发优化,有两个建议: 1.    优化事务逻辑 2.    解决mysql高并发热点,这个可以看看阿里的一个热点补丁: http://www.open-open.com/doc/view/d58cadb4fb68429587634a77f93aa13f ------------------------- 回 23楼(aelven) 的帖子 对于第一个问题.需要看看你的数据库架构是什么样的?比如你的架构具有高可用行?具有读写分离的架构?具有群集的架构.数据库应用是否有较冷门的功能。高并发应该不是什么问题。可扩展性方面需要考虑。阿里云数据库提供了很多优势,比如磁盘是性能超好的SSD,自动转移的高可用性,没有任何单点,自动灵活的备份方案,实用的监控报警,性能监控服务等等,省去DBA很多基础性工作。 你第二个问题,看起来是一个高并发的场景,这种高并发的场景容易出现大量的LOCK甚至死锁,我不是很清楚你的业务,但可以建议一下,首先可以考虑快照隔离级别,实现行多版本控制,让读写不要阻塞。至于写写过程,需要加锁的粒度降低最低,同时这种高并发也容易出现死锁,关于死锁的分析,本帖有提到,请关注。 第三个问题,你用ECS搭建自己的应用也是可以的,RDS数据库提供了很多功能,上面已经讲到了。安全问题一直是我们最看重的问题,肯定有超好的防护的。 ------------------------- 回 26楼(板砖大叔) 的帖子 我曾经整理的关于索引的设计与规范,可以供你参考: ----------------------------------------------------------------------- 索引设计与规范 1.1    使用索引 SQL SERVER没有索引也可以检索数据,只不过检索数据时扫描这个表而异。存储数据的目的,绝大多数都是为了再次使用,而一般数据检索都是带条件的检索,数据查询在数据库操作中会占用较大的比例,提高查询的效率往往意味着整个数据库性能的提升。索引是特定列的有序集合。索引使用B-树结构,最小优化了定位所需要的键值的访问页面量,包含聚集索引和非聚集索引两大类。聚集索引与数据存放在一起,它决定表中数据存储的物理顺序,其叶子节点为数据行。 1.2    聚集索引 1.2.1    关于聚集索引 没聚集索引的表叫堆。堆是一种没有加工的数据,以行标示符作为指向数据存储位置的指针,数据没有顺序。聚集索引的叶子页面和表的数据页面相同,因此表行物理上按照聚集索引列排序,表数据的物理顺序只有一种,所以一个表只有一个聚集索引。 1.2.2    与非聚集索引关系 非聚集索引的一个索引行包含指向表对应行的指针,这个指针称为行定位器,行定位器的值取决于数据页保存为堆还是被聚集。若是堆,行定位器指向的堆中数据行的行号指针,若是聚集索引表,行定位器是聚集索引键值。 1.2.3    设计聚集索引注意事项     首先创建聚集索引     聚集索引上的列需要足够短     一步重建索引,不要使用先DROP再CREATE,可使用DROP_EXISTING     检索一定范围和预先排序数据时使用,因为聚集索引的叶子与数据页面相同,索引顺序也是数据物理顺序,读取数据时,磁头是按照顺序读取,而不是随机定位读取数据。     在频繁更新的列上不要设计聚集索引,他将导致所有的非聚集所有的更新,阻塞非聚集索引的查询     不要使用太长的关键字,因为非聚集索引实际包含了聚集索引值     不要在太多并发度高的顺序插入,这将导致页面分割,设置合理的填充因子是个不错的选择 1.3    非聚集索引 1.3.1    关于非聚集索引 非聚集索引不影响表页面中数据的顺序,其叶子页面和表的数据页面时分离的,需要一个行定位器来导航数据,在将聚集索引时已经有说明,非聚集索引在读取少量数据行时特别有效。非聚集索引所有可以有多个。同时非聚集有很多其他衍生出来的索引类型,比如覆盖索引,过滤索引等。 1.3.2    设计非聚集索引     频繁更新的列,不适合做聚集索引,但可以做非聚集索引     宽关键字,例如很宽的一列或者一组列,不适合做聚集索引的列可作非聚集索引列     检索大量的行不宜做非聚集索引,但是可以使用覆盖索引来消除这种影响 1.3.3    优化书签查找 书签会访问索引之外的数据,在堆表,书签查找会根据RID号去访问数据,若是聚集索引表,一般根据聚集索引去查找。在查询数据时,要分两个部分来完成,增加了读取数据的开销,增加了CPU的压力。在大表中,索引页面和数据页面一般不会临近,若数据只存在磁盘,产生直接随机从磁盘读取,这导致更多的消耗。因此,根据实际需要优化书签查找。解决书签查找有如下方法:     使用聚集索引避免书签查找     使用覆盖索引避免书签查找     使用索引连接避免数据查找 1.4    聚集与非聚集之比较 1.4.1    检索的数据行 一般地,检索数据量大的一般使用聚集索引,因为聚集索引的叶子页面与数据页面在相同。相反,检索少量的数据可能非聚集索引更有利,但注意书签查找消耗资源的力度,不过可考虑覆盖索引解决这个问题。 1.4.2    数据是否排序 如果数据需要预先排序,需要使用聚集索引,若不需要预先排序就那就选择聚集索引。 1.4.3    索引键的宽度 索引键如果太宽,不仅会影响数据查询性能,还影响非聚集索引,因此,若索引键比较小,可以作为聚集索引,如果索引键够大,考虑非聚集索引,如果很大的话,可以用INCLUDE创建覆盖索引。 1.4.4    列更新的频度 列更新频率高的话,应该避免考虑所用非聚集索引,否则可考虑聚集索引。 1.4.5    书签查找开销 如果书签查找开销较大,应该考虑聚集索引,否则可使用非聚集索引,更佳是使用覆盖索引,不过得根据具体的查询语句而看。 1.5    覆盖索引 覆盖索引可显著减少查询的逻辑读次数,使用INCLUDE语句添加列的方式更容易实现,他不仅减小索引中索引列的数据,还可以减少索引键的大小,原因是包含列只保存在索引的叶子级别上,而不是索引的叶子页面。覆盖索引充当一个伪的聚集索引。覆盖索引还能够有效的减少阻塞和死锁的发生,与聚集索引类似,因为聚集索引值发生一次锁,非覆盖索引可能发生两次,一次锁数据,一次锁索引,以确保数据的一致性。覆盖索引相当于数据的一个拷贝,与数据页面隔离,因此也只发生一次锁。 1.6    索引交叉 如果一个表有多个索引,那么可以拥有多个索引来执行一个查询,根据每个索引检索小的结果集,然后就将子结果集做一个交叉,得到满足条件的那些数据行。这种技术可以解决覆盖索引中没有包含的数据。 1.7    索引连接 几乎是跟索引交叉类似,是一个衍生品种。他将覆盖索引应用到交叉索引。如果没有单个覆盖索引查询的索引而多个索引一起覆盖查询,SQL SERVER可以使用索引连接来完全满足查询而不需要查询基础表。 1.8    过滤索引 用来在可能没有好的选择性的一个或者多个列上创建一个高选择性的关键字组。例如在处理NULL问题比较有效,创建索引时,可以像写T-SQL语句一样加个WHERE条件,以排除某部分数据而检索。 1.9    索引视图 索引视图在OLAP系统上可能有胜算,在OLTP会产生过大的开销和不可操作性,比如索引视图要求引用当前数据库的表。索引视图需要绑定基础表的架构,索引视图要求企业版,这些限制导致不可操作性。 1.10    索引设计建议 1.10.1    检查WHERE字句和连接条件列 检查WHERE条件列的可选择性和数据密度,根据条件创建索引。一般地,连接条件上应当考虑创建索引,这个涉及到连接技术,暂时不说明。 1.10.2    使用窄的索引 窄的索引有可减少IO开销,读取更少量的数据页。并且缓存更少的索引页面,减少内存中索引页面的逻辑读取大小。当然,磁盘空间也会相应地减少。 1.10.3    检查列的唯一性 数据分布比较集中的列,种类比较少的列上创建索引的有效性比较差,如果性别只有男女之分,最多还有个UNKNOWN,单独在上面创建索引可能效果不好,但是他们可以为覆盖索引做出贡献。 1.10.4    检查列的数据类型 索引的数据类型是很重要的,在整数类型上创建的索引比在字符类型上创建索引更有效。同一类型,在数据长度较小的类型上创建又比在长度较长的类型上更有效。 1.10.5    考虑列的顺序 对于包含多个列的索引,列顺序很重要。索引键值在索引上的第一上排序,然后在前一列的每个值的下一列做子排序,符合索引的第一列通常为该索引的前沿。同时要考虑列的唯一性,列宽度,列的数据类型来做权衡。 1.10.6    考虑索引的类型 使用索引类型前面已经有较多的介绍,怎么选择已经给出。不再累述。 ------------------------- 回 27楼(板砖大叔) 的帖子 这两种都可以吧。看个人的喜好,不过微软现在的统一风格是下划线,比如表sys.all_columns/sys.tables,然后你再看他的列全是下划线连接,name     /object_id    /principal_id    /schema_id    /parent_object_id      /type    /type_desc    /create_date    /modify_date 我个人的喜好也是喜欢下划线。    

石沫 2019-12-02 01:34:30 0 浏览量 回答数 0

问题

Vue面试题汇总【精品问答】

问问小秘 2020-05-25 18:02:28 63 浏览量 回答数 1

问题

【精品锦集】MySQL热门回答01

问问小秘 2019-12-01 19:51:42 82 浏览量 回答数 1

回答

回1楼maikellycai的帖子 那方面的设置问题啊?求详解哈,谢谢 ------------------------- 回3楼bcaiwa的帖子 配置如下: CPU: 1核    内存: 2GB  数据盘: 5G    带宽: 2Mbps 我想应该不是配置的问题吧? ------------------------- 回2楼holdb的帖子 不知道怎么解决啊? ------------------------- 回7楼服务器之家的帖子 怎么优化啊?之前用win7系统就感觉很慢,但是访问还是没问题的。可换了linux,现在倒好直接访问不了了。

氧分子网 2019-12-01 23:23:56 0 浏览量 回答数 0

问题

【精品问答】初级程序员必备2020最新MYSQL面试题

问问小秘 2020-03-31 13:32:17 1670 浏览量 回答数 1
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 SQL审核 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站 人工智能 阿里云云栖号 云栖号案例 云栖号直播