Запрос занимает очень много времени в клиентском приложении, но быстро в SQL Server Management Studio

я разрабатываю приложение, которое хранит изображения и связанные метаданные. У меня возникают проблемы при выполнении определенного запроса с помощью NHibernate. Запрос занимает непомерно много времени (на моей машине около 31 секунды), хотя один и тот же запрос занимает всего лишь долю секунды при выполнении в среде SQL Server Management Studio.

я уменьшил и извлек проблему до небольшого теста применение:

объекты:

Tag, состоящий из Id (строка, само значение тега)

public class Tag
{
    public virtual string Id { get; set; }
}

изображения, состоящий из Id (int), Name (string) и тегов (many-to-many, set of Tag экземпляров)

public class Image
{
    private Iesi.Collections.Generic.ISet<Tag> tags = new HashedSet<Tag>();

    public virtual int Id { get; set; }

    public virtual string Name { get; set; }

    public virtual IEnumerable<Tag> Tags
    {
        get { return tags; }
    }

    public virtual void AddTag(Tag tag)
    {
        tags.Add(tag);
    }
}

я использую "сопоставление по коду" со следующими сопоставлениями:

public class TagMapping : ClassMapping<Tag>
{
    public TagMapping()
    {
        Id(x => x.Id, map => map.Generator(Generators.Assigned));
    }
}

public class ImageMapping : ClassMapping<Image>
{
    public ImageMapping()
    {
        Id(x => x.Id, map => map.Generator(Generators.Native));
        Property(x => x.Name);
        Set(x => x.Tags, 
            map => map.Access(Accessor.Field),
            map => map.ManyToMany(m2m => { }));
    }
}

конфигурация NHibernate / database выглядит следующим образом:

  <hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
    <session-factory>
      <property name="dialect">NHibernate.Dialect.MsSql2008Dialect</property>
      <property name="connection.connection_string_name">PrimaryDatabase</property>
        <property name="format_sql">true</property>
    </session-factory>
  </hibernate-configuration>
  <connectionStrings>
    <add name="PrimaryDatabase" providerName="System.Data.SqlClient" connectionString="Data Source=.SQLEXPRESS;Initial Catalog=PerfTest;Integrated Security=True" />
  </connectionStrings>

я хочу выполните следующий запрос: дайте мне все изображения, где имя содержит определенную строку или где любой тег содержит определенную строку. Чтобы найти последнее, я использую подзапрос, который дает мне идентификаторы всех изображений с соответствующими тегами. Таким образом, в конечном итоге критерии поиска: изображение имеет имя, содержащее определенную строку, или его идентификатор является одним из возвращаемых подзапросом.

вот код, который выполняет запрос:

var term = "abc";
var mode = MatchMode.Anywhere;

var imagesWithMatchingTag = QueryOver.Of<Image>()
    .JoinQueryOver<Tag>(x => x.Tags)
    .WhereRestrictionOn(x => x.Id).IsLike(term, mode)
    .Select(x => x.Id);

var qry = session.QueryOver<Image>()
    .Where( Restrictions.On<Image>(x => x.Name).IsLike(term, mode) ||
            Subqueries.WhereProperty<Image>(x => x.Id).In(imagesWithMatchingTag))
    .List();

тестовая база данных (СУБД: SQL Server 2008 Express R2) я запускаю этот запрос против был создан специально для этого теста и не содержит ничего другого. Я заполнил его случайными данными: 10.000 изображений (табл.изображения), теги 4.000 (таблица Tag) и примерно 200.000 ассоциаций между изображениями и тегами (таблица Теги), т. е.. каждое изображение имеет около 20 тегов. База данных

утверждения SQL NHibernate для использования:

SELECT
    this_.Id as Id1_0_,
    this_.Name as Name1_0_
FROM
    Image this_
WHERE
    (
        this_.Name like @p0
        or this_.Id in (
            SELECT
                this_0_.Id as y0_
            FROM
                Image this_0_
            inner join
                Tags tags3_
                    on this_0_.Id=tags3_.image_key
            inner join
                Tag tag1_
                    on tags3_.elt=tag1_.Id
            WHERE
                tag1_.Id like @p1
        )
    );
@p0 = '%abc%' [Type: String (4000)], @p1 = '%abc%' [Type: String (4000)]

это выглядит разумным с учетом запрос, который я создаю.

если я запускаю этот запрос с помощью NHibernate, запрос занимает около 30 + секунд (NHibernate.AdoNet.AbstractBatcher - ExecuteReader took 32964 ms) и возвращает 98 лиц.

однако, если я выполняю эквивалентный запрос непосредственно в среде SQL Server Management studio:

DECLARE @p0 nvarchar(4000)
DECLARE @p1 nvarchar(4000)

SET @p0 = '%abc%'
SET @p1 = '%abc%'    

SELECT
    this_.Id as Id1_0_,
    this_.Name as Name1_0_
FROM
    Image this_
WHERE
    (
        this_.Name like @p0
        or this_.Id in (
            SELECT
                this_0_.Id as y0_
            FROM
                Image this_0_
            inner join
                Tags tags3_
                    on this_0_.Id=tags3_.image_key
            inner join
                Tag tag1_
                    on tags3_.elt=tag1_.Id
            WHERE
                tag1_.Id like @p1
        )
    );

запрос занимает гораздо меньше одной секунды (и возвращает 98 результатов).

дальнейшие эксперименты:

если я только поиск по имени или только по тегам, то есть.:

var qry = session.QueryOver<Image>()
    .Where( Subqueries.WhereProperty<Image>(x => x.Id).In(imagesWithMatchingTag))
    .List();

или

var qry = session.QueryOver<Image>()
    .Where(Restrictions.On<Image>(x => x.Name).IsLike(term, mode))
    .List();

запросы быстро.

если я не использую like, но точное совпадение в моем подзапросе:

var imagesWithMatchingTag = QueryOver.Of<Image>()
    .JoinQueryOver<Tag>(x => x.Tags)
    .Where(x => x.Id == term)
    .Select(x => x.Id);

запрос тоже быстрый.

изменение режима соответствия для точного имени ничего не меняет.

когда я отлаживаю программу и приостанавливаю выполнение запроса, верхняя часть стека управляемых вызовов выглядит так:

[Managed to Native Transition]   
System.Data.dll!SNINativeMethodWrapper.SNIReadSync(System.Runtime.InteropServices.SafeHandle pConn, ref System.IntPtr packet, int timeout) + 0x53 bytes  
System.Data.dll!System.Data.SqlClient.TdsParserStateObject.ReadSni(System.Data.Common.DbAsyncResult asyncResult, System.Data.SqlClient.TdsParserStateObject stateObj) + 0xa3 bytes   
System.Data.dll!System.Data.SqlClient.TdsParserStateObject.ReadNetworkPacket() + 0x24 bytes  
System.Data.dll!System.Data.SqlClient.TdsParserStateObject.ReadBuffer() + 0x1f bytes     
System.Data.dll!System.Data.SqlClient.TdsParserStateObject.ReadByte() + 0x46 bytes   
System.Data.dll!System.Data.SqlClient.TdsParser.Run(System.Data.SqlClient.RunBehavior runBehavior, System.Data.SqlClient.SqlCommand cmdHandler, System.Data.SqlClient.SqlDataReader dataStream, System.Data.SqlClient.BulkCopySimpleResultSet bulkCopyHandler, System.Data.SqlClient.TdsParserStateObject stateObj) + 0x67 bytes     
System.Data.dll!System.Data.SqlClient.SqlDataReader.ConsumeMetaData() + 0x22 bytes   
System.Data.dll!System.Data.SqlClient.SqlDataReader.MetaData.get() + 0x57 bytes  
System.Data.dll!System.Data.SqlClient.SqlCommand.FinishExecuteReader(System.Data.SqlClient.SqlDataReader ds, System.Data.SqlClient.RunBehavior runBehavior, string resetOptionsString) + 0xe1 bytes  
...

Итак, мои вопросы являются:

• почему запрос так долго выполняется NHibernate, даже если используемый SQL тот же?
• как я могу избавиться от разница? Есть ли параметр, который может вызвать такое поведение?

я знаю, что запрос в целом не самая эффективная вещь в мире, но то, что поражает меня здесь, - это разница между использованием NHibernate и ручным запросом. Определенно происходит что-то странное. здесь.

извините за длинный пост, но я хотела включить как можно больше о проблеме. Большое спасибо заранее за вашу помощь!

обновление 1: Я тестировал приложение с NHProf без особой дополнительной ценности: NHProf показывает, что выполняемый SQL

SELECT this_.Id   as Id1_0_,
       this_.Name as Name1_0_
FROM   Image this_
WHERE  (this_.Name like '%abc%' /* @p0 */
         or this_.Id in (SELECT this_0_.Id as y0_
                         FROM   Image this_0_
                                inner join Tags tags3_
                                  on this_0_.Id = tags3_.image_key
                                inner join Tag tag1_
                                  on tags3_.elt = tag1_.Id
                         WHERE  tag1_.Id like '%abc%' /* @p1 */))

что именно то, что я опубликовал раньше (потому что это то, что NHibernate написал в свой журнал в первую очередь).

вот скриншот NHProf

предупреждения понятны, но не объясняют поведение.

обновление 2 @surfen sugested, чтобы сначала вытащить результаты подзапроса из БД и вставить их обратно в основной запрос:

var imagesWithMatchingTag = QueryOver.Of<Image>()
    .JoinQueryOver<Tag>(x => x.Tags)
    .WhereRestrictionOn(x => x.Id).IsLike(term, mode)
    .Select(x => x.Id);

var ids = imagesWithMatchingTag.GetExecutableQueryOver(session).List<int>().ToArray();

var qry = session.QueryOver<Image>()
    .Where(
            Restrictions.On<Image>(x => x.Name).IsLike(term, mode) ||
            Restrictions.On<Image>(x => x.Id).IsIn(ids))
    .List();

хотя это действительно делает основной запрос снова быстрым, я бы предпочел не использовать этот подход, поскольку он не подходит для предполагаемого использования в реальном приложении. Интересно, что это так много но быстрее. Я ожидаю, что подход подзапроса будет одинаково быстрым, учитывая, что он не зависит от внешнего запроса.

обновление 3 Это, похоже, не связано с NHibernate. Если я запускаю запрос с помощью normal ADO.NET объекты я получаю такое же поведение:

var cmdText = @"SELECT this_.Id   as Id1_0_,
                        this_.Name as Name1_0_
                FROM   Image this_
                WHERE  (this_.Name like  @p0 
                            or this_.Id in 
                        (SELECT this_0_.Id as y0_
                        FROM   Image this_0_
                            inner join Tags tags3_
                                on this_0_.Id = tags3_.image_key
                            inner join Tag tag1_
                                on tags3_.elt = tag1_.Id
                        WHERE  tag1_.Id like  @p1 ));";

using (var con = new SqlConnection(ConfigurationManager.ConnectionStrings["PrimaryDatabase"].ConnectionString))
{
    con.Open();
    using (var txn = con.BeginTransaction())
    {
        using (var cmd = new SqlCommand(cmdText, con, txn))
        {
            cmd.CommandTimeout = 120;
            cmd.Parameters.AddWithValue("p0", "%abc%");
            cmd.Parameters.AddWithValue("p1", "%abc%");

            using (var reader = cmd.ExecuteReader())
            {
                while (reader.Read())
                {
                    Console.WriteLine("Match");
                }
            }

        }
        txn.Commit();
    }
}

обновление 4

Query-plans (нажмите, чтобы увеличить):

медленный запрос

быстрый запрос

там определенно есть разница в плане.

обновление 5

поскольку кажется, что Sql Server рассматривает подзапрос как коррелированный, я попробовал что-то другое: я переместил критерий, связанный с именем, в подзапрос сам по себе:

var term = "abc";
var mode = MatchMode.Anywhere;

var imagesWithMatchingTag = QueryOver.Of<Image>()
    .JoinQueryOver<Tag>(x => x.Tags)
    .WhereRestrictionOn(x => x.Id).IsLike(term, mode)
    .Select(x => x.Id);

var imagesWithMatchingName = QueryOver.Of<Image>()
    .WhereRestrictionOn(x => x.Name).IsLike(term, mode)
    .Select(x => x.Id);

var qry = session.QueryOver<Image>()
    .Where(
      Subqueries.WhereProperty<Image>(x => x.Id).In(imagesWithMatchingName) ||        
      Subqueries.WhereProperty<Image>(x => x.Id).In(imagesWithMatchingTag) 
    ).List();

сгенерированный SQL-код:

SELECT
    this_.Id as Id1_0_,
    this_.Name as Name1_0_
FROM
    Image this_
WHERE
    (
        this_.Id in (
            SELECT
                this_0_.Id as y0_
            FROM
                Image this_0_
            inner join
                Tags tags3_
                    on this_0_.Id=tags3_.image_key
            inner join
                Tag tag1_
                    on tags3_.elt=tag1_.Id
            WHERE
                tag1_.Id like @p0
        )
        or this_.Id in (
            SELECT
                this_0_.Id as y0_
            FROM
                Image this_0_
            WHERE
                this_0_.Name like @p1
        )
    );
@p0 = '%abc%' [Type: String (4000)], @p1 = '%abc%' [Type: String (4000)]

это, похоже, нарушает корреляцию, и в результате запрос снова становится "быстрым" ("быстрым", как в "приемлемом на данный момент"). Время запроса пошел вниз от 30 + секунд до ~170ms. Все еще не легкий запрос, но, по крайней мере, позволит мне продолжить отсюда. Я знаю, что "like '%foo%'" никогда не будет супер быстрой. Если дело дойдет до худшего, я все равно могу перейти на специализированный поисковый сервер (Lucene, solr) или реальный полнотекстовый поиск.

обновление 6 Я смог переписать запрос, чтобы вообще не использовать подзапросы:

var qry = session.QueryOver(() => img)
    .Left.JoinQueryOver(x => x.Tags, () => tag)
    .Where(
        Restrictions.Like(Projections.Property(() => img.Name), term, mode) ||
        Restrictions.Like(Projections.Property(() => tag.Id), term, mode))
    .TransformUsing(Transformers.DistinctRootEntity)
    .List();

SQL:

SELECT
    this_.Id as Id1_1_,
    this_.Name as Name1_1_,
    tags3_.image_key as image1_3_,
    tag1_.Id as elt3_,
    tag1_.Id as Id0_0_
FROM
    Image this_
left outer join
    Tags tags3_
        on this_.Id=tags3_.image_key
left outer join
    Tag tag1_
        on tags3_.elt=tag1_.Id
WHERE
    (
        this_.Name like @p0
        or tag1_.Id like @p1
    );
@p0 = '%abc%' [Type: String (4000)], @p1 = '%abc%' [Type: String (4000)]

однако запрос выполняется сейчас немного хуже, чем версия с подзапросами. Я продолжу расследование.