blocks|key|586808|text|找到答案的最好方法是创建一系列类似于现实生活中的测试查询，并尝试使用和不使用索引的方式对您的DB运行它们。但是，通常情况下，如果您正在执行许多SELECT查询，很少有更新/删除查询，那么索引可能会使您的查询更快。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|586809|但是，如果您做了大量更新，索引可能会损害您的性能，因此您必须知道您的DB在做出此决定之前必须处理什么样的查询。|586810|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The best way to find out is to create a bunch of test queries that resemble what would happen in real life and try to run them against your DB with and without the index. However, in general, if you are doing many SELECT queries, and little UPDATE/DELETE queries, an index might make your queries faster. 

However, if you do a lot of updates, the index might hurt your performance, so you have to know what kind of queries your DB will have to deal with before you make this decision.

blocks|key|713139|text|如果您正在执行“%25关键字%25”搜索，那么创建常规索引是不值得的。原因是索引的工作原理就像搜索字典，从中间开始，然后再将差异平分，直到找到单词为止。这个通配符查询就像要求您查找一个包含文本"+to“或其他什么的单词--查找匹配的唯一方法是扫描整个字典。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|713140|然而，您可能会考虑进行全文搜索，这是针对这种场景(请看这里)的。|713141|entityMap|0|LINK|mutability|MUTABLE|url|https://learn.microsoft.com/en-us/sql/relational-databases/search/full-text-search?view=sql-server-2017^0|E|32|0|0|W|P|4|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@$9|V|A|W|1|X]]|E|$]]|$1|H|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

It's not worthwhile creating a regular index if you're doing LIKE '%keyword%' searches. The reason is that indexing works like searching a dictionary, where you start in the middle then split the difference until you find the word. That wildcard query is like asking you to lookup a word that contains the text "to" or something-- the only way to find matches is to scan the whole dictionary.

You might consider a full-text search, however, which is meant for this kind of scenario (<a href="https://learn.microsoft.com/en-us/sql/relational-databases/search/full-text-search?view=sql-server-2017" rel="nofollow noreferrer">see here</a>).

blocks|key|713170|text|不能在varchar(max)字段上创建索引。索引上的最大字节数为900。如果列大于900字节，则可以创建索引，但任何大于900字节的插入都将失败。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|713171|我建议你读一下关于全文搜索的文章。在这种情况下它应该适合你。|offset|length|713172|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/ms142571%2528v=sql.100%2529.aspx^0|0|9|2|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

you cannot create an index on a varchar(max) field. The maximum amount of bytes on a index is 900. If the column is bigger than 900 bytes, you can create the index but any insert with more then 900 bytes will fail.

I suggest you to read about <a href="http://msdn.microsoft.com/en-us/library/ms142571%28v=sql.100%29.aspx">fulltext</a> search. It should suits you in this case

blocks|key|586853|text|对于为什么索引无助于'%25wildcard%25'搜索，这是我见过的最好的类比：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|586854|带两个人去。把同一本电话簿递给每个人。对你左边的人说：|586855|告诉我，这本电话簿上有多少人姓“史密斯”，。|BOLD|586856|现在对你右边的人说：|586857|告诉我，这本电话簿上有多少人的名字叫“西蒙”。|586858|索引就像电话簿。很容易找到最初的东西。很难扫描的东西是在中间或结尾。|586859|每次我在一次会议上重复这一点，我都会看到灯泡还在继续，所以我觉得在这里分享可能是有用的。|586860|entityMap^0|A|C|0|0|0|L|0|0|0|M|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|Y|8|@$9|Z|A|10|B|J]]|D|@]|E|$]]|$1|K|3|L|5|6|7|11|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|12|8|@$9|13|A|14|B|J]]|D|@]|E|$]]|$1|O|3|P|5|6|7|15|8|@]|D|@]|E|$]]|$1|Q|3|R|5|6|7|16|8|@]|D|@]|E|$]]|$1|S|3|-4|5|6|7|17|8|@]|D|@]|E|$]]]|T|$]]

The best analogy I've ever seen for why an index won't help <code>'%wildcard%'</code> searches:

Take two people. Hand each one the same phone book. Say to the person on your left: 

Tell me how many people are in this phone book with the last name "Smith."

Now say to the person on your right:

Tell me how many people are in this phone book with the first name "Simon."

An index is like a phone book. Very easy to seek for the thing that is at the beginning. Very difficult to scan for the thing that is in the middle or at the end.

Every time I've repeated this in a session, I see light bulbs go on, so I thought it might be useful to share here.

Firstly, I should point out I don't have much knowledge on SQL Server indexes.

My situation is that I have an SQL Server 2008 database table that has a varchar(max) column usually filled with a lot of text.

My ASP.NET web application has a search facility which queries this column for keyword searches, and depending on the number of keywords searched for their may be one or many LIKE '%keyword%' statements in the SQL query to do the search.

My web application also allows searching by various other columns in this table as well, not just that one column. There is also a few joins from other tables too.

My question is, is it worthwhile creating an index on this column to improve performance of these search queries? And if so, what type of index, and will just indexing the one column be enough or do I need to include other columns such as the primary key and other searchable columns?

Will indexing improve varchar(max) query performance, and how to create index

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

首先，我要指出，我对Server索引了解不多。我的情况是，我有一个Server 2008数据库表，其中包含一个varchar(max)列，该列通常包含大量文本。我的ASP.NET web应用程序有一个搜索工具，它可以查询此列的关键字搜索，并根据搜索关键字的数量而定，它们可能是一个或多个类似于SQL中的‘%关键字%’语句...

问索引将提高varchar(max)查询性能，以及如何创建索引
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问索引将提高varchar(max)查询性能，以及如何创建索引EN