wordpress百万级 wordpress文章过十万

我为什么放弃WordPress

首先要明白一个东西：什么称作访问量大?日均一万PV?还是十万PV?或者百万千万级别?网站的访问量增大的时候，意味着服务器压力也变大，这可不能单纯的去用换网站程序来解决，还需要更多的应该是从服务器、数据池等方面去着手。同理，当你的博客达到百万级PV的时候，我想无论任何一款博客程序的默认性能都无法让你满足。据我在圈内的一些使用WP作为博客程序的朋友，WP日均十万PV还是很容易办到的。而如果上了百万级别的PV，想让WP自己去解决这想法也太2了吧?真的有百万级别，那时你应该有足够的钱和信心去请专门的人来帮你做服务器和程序的优化，还有什么好担心的呢?

创新互联-专业网站定制、快速模板网站建设、高性价比西华网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式西华网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖西华地区。费用合理售后完善，10余年实体公司更值得信赖。

另一个例子是，无论是国内还是国外，大部分的访问量较高的独立博客，基本上都采用WordPress(特别是科技类的博客)，这算是他们的噩梦吗?显然不是，当访问量高了之后，他们有自己的办法。

WordPress对于服务器资源的占用，并没有那么夸张。最关键的一点，作为普通的个人博客，不应该把这些问题扣在WP上，而应该让主机空间服务商去解决，他们作为商业运作的机构，是应该主动迎合潮流迎合WP，做更多的优化策略，而不是将WP拒之门外，也没有哪个主机空间商敢主动把WP拒之门外，这无非是他们自己发发牢骚罢了。这就好比计算机软件，电脑游戏，时代在发展，总是硬件商去迎合游戏的性能需求，而不是让游戏降低硬件需求。

Wordpress能应对百万级别数据量吗

处理是没有问题的，但是wordpress的数据库架构，是有点问题的，需要站长自己优化好数据库才行，不然处理很缓慢。

wordpress能承载多大的数据？文章数量如果十万，百万

wordpress能承载多大数据，主要是看数据库的承载能力，

也就是看mysql的承载能力了。

十万、百万应该是没有问题的。

希望我的回答帮到你。

wordpress百万级数据如何优化数据库

MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，目前属于 Oracle 旗下产品。MySQL 是最流行的关系型数据库管理系统之一，在 WEB 应用方面，MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件。“总是在灾难发生后，才想起容灾的重要性。总是在吃过亏后，才记得曾经有人提醒过。”，所以此处列出一些MySQL的必要的优化和建议。

1. 核心类

♦ 不在数据库做计算，cpu计算务必移至业务层；

♦ 控制单表数据量，单表记录控制在千万级；

♦ 控制列数量，字段数控制在20以内；

♦ 平衡范式与冗余，为提高效率可以牺牲范式设计，冗余数据；

♦ 拒绝3B(big)，大sql，大事务，大批量；

2. 字段类

♦ 用好数值类型

tinyint(1Byte)

smallint(2Byte)

mediumint(3Byte)

int(4Byte)

bigint(8Byte)

bad case：int(1)/int(11)

♦ 有些字符转化为数字

例如：用int而不是char(15)存储ip

♦ 优先使用enum或set

例如：sex enum (‘F’, ‘M’)

♦ 避免使用NULL字段

NULL字段很难查询优化

NULL字段的索引需要额外空间

NULL字段的复合索引无效

bad case：

name char(32) default null

age int not null

good case：

age int not null default 0

♦ 不在数据库里存图片

3. 索引类

♦ 谨慎合理使用索引

改善查询、减慢更新

索引一定不是越多越好（能不加就不加，要加的一定得加）

覆盖记录条数过多不适合建索引，例如“性别”

♦ 字符字段必须建前缀索引

♦ 不在索引做列运算

bad case：

select id where age +1 = 10;

♦ innodb 主键合理使用自增列

主键建立聚簇索引

主键不应该被修改

字符串不应该做主键

如果不指定主键，innodb会使用唯一且非空值索引代替

♦ 不用外键，请由程序保证约束

4. sql类

♦ sql语句尽可能简单

一条sql只能在一个cpu运算

大语句拆小语句，减少锁时间

一条大sql可以堵死整个库

♦ 简单的事务

事务时间尽可能短

bad case：

上传图片事务

♦ 避免使用触发器，用户自定义函数，请由程序取而代之

♦ 不用select *

消耗cpu，io，内存，带宽

这种程序不具有扩展性

♦ OR改写为IN()

♦ OR改写为UNION

PS：最新的mysql内核已经进行了相关优化

♦ limit高效分页

limit越大，效率越低

select id from t limit 10000, 10;

应该改为 =

select id from t where id 10000 limit 10;

♦ 使用union all替代union，union有去重开销

♦ 尽量不用连接join

♦ 务必请使用“同类型”进行比较，否则可能全表扫面

♦ 打散批量更新

♦ 使用新能分析工具

show profile;

mysqlsla;

mysqldumpslow;

explain;

show slow log;

show processlist;

show query_response_time(percona)