Как объединения влияют на то, какие индексы используются?

Question

Как объединения влияют на то, какие индексы используются?

sub get_reader {
   my ($cmd) = @_;

   open(my $pipe, '-|', @$cmd);

   return sub {
      return undef if !$pipe;

      my $line = <$pipe>;
      if (!defined($line)) {
         close($pipe);
         $pipe = undef;
         return undef;
      }

      chomp($line);
      return $line;
   };
}

Если это недостаточно, (например, потому что вам также необходимо перенаправить STDIN или STDERR), вы можете использовать IPC :: Run вместо.

use IPC::Run qw( start );

sub get_reader {
   my ($cmd) = @_;

   my $buf = '';
   my $h = start($cmd, '>', \$buf);

   return sub {
      return undef if !$h;

      while (1) {
         if ($buf =~ s/^([^\n]*)\n//) {
            return $1;
         }

         if (!$h->pump())) {
            $h->finish();
            $h = undef;
            return substr($buf, 0, length($buf), '') if length($buf);
            return undef;
         }
      }
   };
}

В любом случае, вы можете теперь do

my $i = get_reader(['prog', 'arg', 'arg']);
while (defined( my $line = $i->() )) {
   print "$line\n";
}

В любом случае, обработка ошибок осталась вам.

4

sql sql-server

задан Boann 19 January 2019 в 17:52

1 ответ

Другие вопросы по тегам:

sql sql-server

Похожие вопросы:

score 0 · Answer 1

В общем, желательно, как минимум, добавить некластеризованный индекс для всех ваших внешних ключей, поскольку они, вероятно, будут часто использоваться в операциях JOIN (а иногда и в предикатах WHERE).

Если говорить конкретно о вашей ситуации, выбранный вами индекс содержит поле VARCHAR(MAX), которое будет влиять на то, как SQL Server решит его использовать. Поскольку VARCHAR(MAX) теоретически может расти до 2 ГБ данных, движок не будет хранить полевые данные на уровне страницы, поскольку он ограничен 8 КБ. В этом случае SQL Server решил, что наименее дорогостоящей операцией является сканирование индекса (что, кстати, не всегда плохо, особенно если селективность высока).

Моя рекомендация: держите индекс жестким и ограничьте его полем UserId, чтобы повысить производительность объединения. Мне не обязательно беспокоиться об индексе покрытия для вашего столбца Content, так как движок должен копать глубже, чем уровень страницы для этих данных.

create nonclustered index ix_posts_userid on dbo.Posts (UserID);

Просто помните, индексы не волшебны и определенно не являются серебряной пулей для всех проблем с производительностью. Правильно спроектированные они могут повысить эффективность системы за счет затрат. Подумайте, «административный персонал в офисе», они нанимают деньги. Но верните бизнесу эффективность в отношении эффективности.

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

Вместо этого сохраняйте теги как общий ресурс и связывайте их через «таблицу соединений».
create table Tags (
    TagId int identity primary key
    ,Content nvarchar(128) not null -- or whatever width suits your needs
);

create table PostTags (
    PostId int not null
    ,TagId int not null
    ,primary key (PostId, TagId)
);