技巧:地区性SEO操作方式
优采云 发布时间: 2022-11-28 15:39技巧:地区性SEO操作方式
21世纪互联网时代,搜索引擎SEO关键词的排名效果是企业的追求。随着广州网络推广公司的快速发展,企业和个人建站变得相对简单。
搜索引擎排名:
(一)广州SEO指标分析关键词
这需要了解关键词的难易程度。一般来说,指标越高,优化难度越大,耗时越长;相反,优化 关键词 的难度要低得多,花费的时间也少得多。
(2)广州SEO关键词的选择
网站建设完成后,大家最关心的就是网站的推广和SEO优化,关键词什么时候才能上榜。
如果你想让你网站的关键词被搜索引擎排名和收录,你首先需要了解最基本的,也就是关于关键词。
" />
您可以先查看关键词被搜索引擎收录的数量,并在下方查看相关的搜索结果。
您也可以使用关键词索引查询工具查询该词的整体搜索索引。
(3)广州SEO竞争对手分析
对于一些索引高、搜索量大的词,短期内是不可能快速做到的。
因为这种关键词的竞争非常激烈,尤其是一些行业大佬。
但是,新网站很难与排名靠前的老网站竞争。需要做的是长期不断优化我们的网站,积累网站的权重,才能逐步提高关键词的排名。
比如新站优化关键词指数为100-200的词,至少需要持续优化一到三个月才能开始产生排名效果。
(4)广州SEO关键词排名效果
" />
1、SEO关键词的排名效果要从实际出发。大词的优化难度会大很多,需要的时间肯定会更长。需要时间和持续有效的优化才能逐步提升和稳定排名。
2、如果是新站点,建议先优化长尾关键词,效果来得更快,也相对容易一些。长尾词的作用不容忽视。这是用户的搜索习惯,也是搜索引擎收录的重点。
3、先优化长尾词对增加网站权重很有帮助,也是后续网站优化的基础。
这里所说的写作能力,不是写小说的能力,不是写诗的能力,不是写剧本的能力。我说的只是最基本的一种写作能力:写得简洁、有效、通俗、准确。用户可以理解的文章。
写一篇原创文章。必须具有一定的材料采集灵敏度。与客户沟通时,一定要敏锐地捕捉客户的需求。比如客户会问“贵公司的产品还能用在哪些领域”、“贵公司的产品安装使用方便吗”等等。
这些可以成为这篇文章的很好材料。您的客户不仅仅搜索产品 关键词。还搜索了与关键词相关的知识技术。撰写此类文章并将其发布在网站上。可以提示网站质量、客户体验、搜索引擎偏好
本片文章总结:做SEO关键词排名是一个持续的实践操作。许多公司通过互联网寻求SEOER精云进行网站推广。在线网站排名提升也更为重要。如果说,很多企业光靠竞价是承担不起网站的竞价费用的。从长远来看,seo关键词排名还是要找网络推广公司。恰好景云SEOER是一家技术团队公司。有需要的可以联系精云SEO。
核心方法:MySQL 慢查询日志 使用方法浅析 日志定位与优化技巧
目录
前言
简单总结就是打开mysql慢查询日志开关并设置预期阈值,查看记录超过预期阈值时间的日志记录并记录慢语句和时间,查看现有查询策略再设置索引,试试优化查询语句和比较查询结果需要时间,最终得到最优解。
1、如何启用和使用慢查询日志?1.1 启用慢查询日志
首先开启慢查询日志(默认关闭),在MySQL命令行输入如下命令:
MySQL > set global slow_query_log=on;
1.2 设置慢查询阈值
如果SQL实际执行时间超过了设定的阈值,就会记录在慢查询日志中。阈值默认为 10s。对于线上业务,一般建议将long_query_time设置为1s。如果某项业务的MySQL对QPS要求比较高,可以将慢查询设置为0.3s。
MySQL > set global long_query_time=1;
1.3 确定慢查询日志的文件名和路径 1.3.1 查询MySQL数据目录
MySQL > show global variables like 'datadir';
1.3.2 查询慢查询日志文件名
MySQL > show global variables like 'slow_query_log_file'
1.3.3 查询全局设置变量
MySQL > show global variables like '%quer%';
1.3.4 查询单个变量命令
MySQL > show status like '%slow_queries%';
1.3.5 其他考虑
当发现慢查询时,及时优化或者提醒开发重写。一般建议在测试环境中将long_query_time的阈值设置的比生产环境小。例如生产环境为1s,测试环境建议设置为0.5s。方便及时在测试环境中找到一些高效的SQL。甚至一些重要的业务测试环境也可以将long_query_time设置为0,以便记录所有语句。并注意慢查询日志的输出。上线前功能测试完成后,分析慢查询日志中各类型语句的输出,重点关注Rows_examined(语句执行时从存储引擎读取的行数)并提前优化。
重启mysql客户端设置,统计慢查询日志数会清空,即恢复所有命令配置修改。只有修改了配置文件才能使修改永久生效,否则重启数据库后数据库会恢复。
2、如何定位和优化慢查询SQL?
1.根据慢日志定位慢查询sql
2.使用explain等工具分析SQL执行计划
3、修改sql或者尽量让sql带索引
2.1 慢查询示例演示 2.1.1 慢查询日志检查执行语句和Query_time参数实际执行时间
Linux > tail -n 500 /var/lib/ mysql/tv6 -hote lqa-newhotel-14-slow.log
查询结果Query_time:6.337729s,SQL执行时间超过1s,所以记录下来,第9行执行语句。
其他参数说明:
2.1.2 其他注意事项
以上方法是查看系统自带的慢查询日志。系统自带的慢查询日志,不方便查看。可以使用pt-query-digest或mysqldumpslow等工具分析慢查询日志。
正在执行一些慢速查询,数据库负载过高。由于慢查询还没有执行,所以在慢查询日志中看不到任何语句。这时候可以使用show processlist命令查看正在执行的慢查询。show processlist 显示哪些线程正在运行。如果您具有 PROCESS 权限,则可以查看所有线程。否则只能看到当前会话线程。
2.2. 查询语句慢怎么办?explain分析sql执行计划 2.2.1 explain分析执行计划
> explain select group_name from groups order by group_name desc;
2.2.2 select_type值表序号
柱子
描述
1个
简单的
简单查询(不使用 UNION 或子查询)
2个
基本的
" />
主查询,外部查询
3个
联盟
UNION 中的第二个或后续语句
4个
联盟结果
UNION的每一个结果集取出后,进行合并操作
5个
依赖子查询
子查询中的第一个 SELECT
6个
依赖联盟
子查询中的 UNION 操作,来自 UNION 中的第二个和所有后续 SELECT 语句
7
衍生的
派生表,FROM 子句中的子查询
8个
物化
物化子查询
9
不可缓存的子查询
子查询的结果无法缓存,外层查询的每一行都必须重新计算
10
不可缓存的联盟
关联查询的第二个或后续语句是不可缓存的子查询
2.2.3 type column,本文ALLl是全表扫描
序列号
类型值
描述
1个
系统
查询对象表只有一行数据,只能用于MySAM和Memory引擎表,是最好的情况
2个
常数
基于主键或唯一索引查询,最多返回一个结果
3个
eq_ref
表join时,根据主键或非NULL的唯一索引完成扫描
4个
参考
基于公共索引的等价查询,或表间等价连接
5个
全文
全文搜索
6个
ref_or_null
表连接类型为ref,但扫描的索引列可能收录
NULL值
7
索引合并
" />
利用多个索引
8个
唯一子查询
在子查询中使用唯一索引
9
索引子查询
在子查询中使用普通索引
10
范围
使用索引的范围查询
11
指数
全索引扫描
12
全部
全表扫描
从上到下的表格代表从最好到最差的 SQL 查询性能。如果type类型为all,则表示SQL语句需要优化。
说明:如果type = NULL,表示MySQL不需要访问表或索引,直接获取结果即可,如explain select sum(1+2);
possible_keys表示可能使用的索引列,key表示实际使用的索引列,以实际使用的索引列为准,是查询优化器优化后选择的,然后我们可以根据实际情况 索引列来查询。
2.2.4 Extra column,这里是Using filesort
必须要注意的是,Extra中出现的Using filesort和Using temporary,意味着MySQL根本不能使用索引,效率会受到严重影响,所以要尽量优化。
Using filesort的出现表明MySQL使用外部索引对结果进行排序,而不是按照索引的顺序从表中读取相关内容。有了索引,B+树就维护好了。数据已经排序,这意味着根本没有使用索引。,但在读取后对数据进行排序,可能在内存或磁盘上。也有人把MySQL中不能使用索引的排序操作称为“文件排序”。Using temporary的出现说明MySQL在对查询结果进行排序时使用了一张临时表,常见于order by和group by查询。
2.2.5 使用索引后,查看慢查询日志,发现查询数据的速度快了2s
MySQL > select name from person_info_large order by name desc;
2.2.6 实战 联合索引与不加索引的查询速度对比
// 添加索引
MySQL > alter table person_ info_ large add index idx_ name(name);
// 查看执行计划
MySQL > explain select name from person_info_large order by name desc;
// 执行查询语句
MySQL > select name from person_ info_large order by name desc;
对比之前name不加索引时的执行计划,会发现加了索引后,type从ALL全表扫描变成了index索引扫描。order by 不使用文件排序,而是使用索引。这里,B+树已经对这个非聚集索引的索引字段的值进行了排序,而不是等查询的时候再排序。
3、当主键索引、唯一索引、公共索引都存在时,查询优化器如何选择?
实际使用哪个索引由查询优化器决定。B+树的叶子节点是链表结构,遍历链表可以统计其个数。但是这张表有主键索引、唯一索引和普通索引。优化器选择帐户作为唯一的帐户。索引,这个肯定不会用到主键索引,因为主键索引是聚簇索引,每个叶子收录
特定的行记录(很多列的数据都在里面),而非聚簇索引的每个叶子只收录
下一个主键索引指针,显然叶子节点收录
的数据越少越好,查询优化器不会选择主键索引。
// 强制使用主键索引,然后分析sql执行计划
MySQL > explain select count(id) from person_ info large force index (primary);
// 优化器默认使用唯一索引大致执行时间
MySQL > select count(id) from person_info_large;
// 强制使用主键索引大致执行时间
MySQL > select count(id) from person_info_large force index (primary);
使用force index强制指定索引,然后分析执行计划看哪个索引更好,因为查询优化器选择的索引不一定100%准确,具体情况可以根据实际场景分析确定确定是否使用查询优化器选择的索引。