Não.

TRUNCATEe DROPsão quase idênticos em comportamento e velocidade, então fazer um TRUNCATEdireito antes de a DROPé simplesmente desnecessário.

Observação: escrevi esta resposta de uma perspectiva do SQL Server e presumi que ela se aplicaria igualmente ao Sybase. Parece que este não é inteiramente o caso .

Nota: Quando publiquei esta resposta pela primeira vez, havia várias outras respostas altamente avaliadas - incluindo a resposta então aceita - que fizeram várias alegações falsas como: TRUNCATEnão está registrado; TRUNCATEnão pode ser revertido; TRUNCATEé mais rápido que DROP; etc.

Agora que este tópico foi limpo, as refutações que se seguem podem parecer tangenciais à pergunta original. Deixo-os aqui como referência para outros que procuram desmascarar esses mitos.

Existem algumas falsidades populares - difundidas mesmo entre DBAs experientes - que podem ter motivado esse TRUNCATE-then-DROPpadrão. Eles são:

• Mito : TRUNCATEnão é registrado, portanto, não pode ser revertido.
• Mito : TRUNCATEé mais rápido que DROP.

Deixe-me refutar essas falsidades. Estou escrevendo esta refutação da perspectiva do SQL Server, mas tudo o que digo aqui deve ser igualmente aplicável ao Sybase.

TRUNCATE é registrado e pode ser revertido.

• TRUNCATEé uma operação registrada, portanto , pode ser revertida . Basta envolvê-lo em uma transação.

  USE [tempdb];
  SET NOCOUNT ON;
  
  CREATE TABLE truncate_demo (
      whatever    VARCHAR(10)
  );
  
  INSERT INTO truncate_demo (whatever)
  VALUES ('log this');
  
  BEGIN TRANSACTION;
      TRUNCATE TABLE truncate_demo;
  ROLLBACK TRANSACTION;
  
  SELECT *
  FROM truncate_demo;
  
  DROP TABLE truncate_demo;
  

  Observe, no entanto, que isso não é verdade para o Oracle . Embora registrado e protegido pela funcionalidade de desfazer e refazer do Oracle, TRUNCATEe outras instruções DDL não podem ser revertidas pelo usuário porque o Oracle emite confirmações implícitas imediatamente antes e depois de todas as instruções DDL.

• TRUNCATEé minimamente registrado , em vez de totalmente registrado. O que isso significa? Diga-lhe TRUNCATEuma mesa. Em vez de colocar cada linha excluída no log de transações, TRUNCATEapenas marca as páginas de dados em que elas residem como não alocadas. Por isso é tão rápido. É também por isso que você não pode recuperar as linhas de uma TRUNCATEtabela -ed do log de transações usando um leitor de log. Tudo o que você encontrará são referências às páginas de dados desalocadas.

  Compare isso com DELETE. Se você DELETEtodas as linhas em uma tabela e confirma a transação, ainda pode, em teoria, encontrar as linhas excluídas no log de transações e recuperá-las de lá. Isso porque DELETEgrava cada linha excluída no log de transações. Para tabelas grandes, isso o tornará muito mais lento do que TRUNCATE.

DROP é tão rápido quanto TRUNCATE.

• Como TRUNCATE, DROPé uma operação minimamente registrada. Isso significa que DROPpode ser revertido também. Isso também significa que funciona exatamente da mesma maneira que o TRUNCATE. Em vez de excluir linhas individuais, DROPmarca as páginas de dados apropriadas como não alocadas e marca adicionalmente os metadados da tabela como excluídos .

• Porque TRUNCATEe DROPfuncionam exatamente da mesma maneira, eles correm tão rápido quanto o outro. Não faz sentido TRUNCATEusar -ing em uma tabela antes DROPde -ing-la. Execute este script de demonstração em sua instância de desenvolvimento se você não acredita em mim.

  Na minha máquina local com um cache quente, os resultados que obtenho são os seguintes:

  table row count: 134,217,728
  
  run#        transaction duration (ms)
        TRUNCATE   TRUNCATE then DROP   DROP
  ==========================================
  01       0               1             4
  02       0              39             1
  03       0               1             1
  04       0               2             1
  05       0               1             1
  06       0              25             1
  07       0               1             1
  08       0               1             1
  09       0               1             1
  10       0              12             1
  ------------------------------------------
  avg      0              8.4           1.3
  

  Portanto, para uma tabela de 134 milhões de linhas, não demora muito. (Em um cache frio , eles levam cerca de 2-3 segundos para a primeira execução ou duas) . ordem de magnitude pior do que as operações individuais. Afinal, são quase exatamente a mesma coisa.DROPTRUNCATETRUNCATEDROP

  Se você estiver interessado em mais detalhes sobre a sobrecarga de log dessas operações, Martin tem uma explicação direta sobre isso.

Testar TRUNCATEentão DROPversus apenas fazer o DROPdiretamente mostra que a primeira abordagem realmente tem uma pequena sobrecarga de registro, portanto, pode até ser levemente contraproducente.

Observar os registros de log individuais mostra que a TRUNCATE ... DROPversão é quase idêntica à DROPversão, exceto por essas entradas adicionais.

+-----------------+---------------+-------------------------+
|    Operation    |    Context    |      AllocUnitName      |
+-----------------+---------------+-------------------------+
| LOP_COUNT_DELTA | LCX_CLUSTERED | sys.sysallocunits.clust |
| LOP_COUNT_DELTA | LCX_CLUSTERED | sys.sysrowsets.clust    |
| LOP_COUNT_DELTA | LCX_CLUSTERED | sys.sysrscols.clst      |
| LOP_COUNT_DELTA | LCX_CLUSTERED | sys.sysrscols.clst      |
| LOP_HOBT_DDL    | LCX_NULL      | NULL                    |
| LOP_MODIFY_ROW  | LCX_CLUSTERED | sys.sysallocunits.clust |
| LOP_HOBT_DDL    | LCX_NULL      | NULL                    |
| LOP_MODIFY_ROW  | LCX_CLUSTERED | sys.sysrowsets.clust    |
| LOP_LOCK_XACT   | LCX_NULL      | NULL                    |
+-----------------+---------------+-------------------------+

Então a TRUNCATEprimeira versão acaba desperdiçando um pouco de esforço fazendo algumas atualizações em várias tabelas do sistema como segue

• Atualização rcmodifiedpara todas as colunas da tabela emsys.sysrscols
• Atualizar rcrowsemsysrowsets
• Zero fora pgfirst, pgroot, pgfirstiam, pcused, pcdata, pcreservedemsys.sysallocunits

Essas linhas da tabela do sistema só acabam sendo excluídas quando a tabela é descartada na próxima instrução.

Um detalhamento completo do registro realizado por TRUNCATEvs DROPestá abaixo. Eu também adicionei DELETEpara fins de comparação.

+-------------------+-------------------+--------------------+------------------+-----------+---------------+-------------+------------------+-----------+---------------+-------------+
|                   |                   |                    |                            Bytes                           |                            Count                           |
+-------------------+-------------------+--------------------+------------------+-----------+---------------+-------------+------------------+-----------+---------------+-------------+
| Operation         | Context           | AllocUnitName      | Truncate / Drop  | Drop Only | Truncate Only | Delete Only | Truncate / Drop  | Drop Only | Truncate Only | Delete Only |
+-------------------+-------------------+--------------------+------------------+-----------+---------------+-------------+------------------+-----------+---------------+-------------+
| LOP_BEGIN_XACT    | LCX_NULL          |                    | 132              | 132       | 132           | 132         | 1                | 1         | 1             | 1           |
| LOP_COMMIT_XACT   | LCX_NULL          |                    | 52               | 52        | 52            | 52          | 1                | 1         | 1             | 1           |
| LOP_COUNT_DELTA   | LCX_CLUSTERED     | System Table       | 832              |           | 832           |             | 4                |           | 4             |             |
| LOP_DELETE_ROWS   | LCX_MARK_AS_GHOST | System Table       | 2864             | 2864      |               |             | 22               | 22        |               |             |
| LOP_DELETE_ROWS   | LCX_MARK_AS_GHOST | T                  |                  |           |               | 8108000     |                  |           |               | 1000        |
| LOP_HOBT_DDL      | LCX_NULL          |                    | 108              | 36        | 72            |             | 3                | 1         | 2             |             |
| LOP_LOCK_XACT     | LCX_NULL          |                    | 336              | 296       | 40            |             | 8                | 7         | 1             |             |
| LOP_MODIFY_HEADER | LCX_PFS           | Unknown Alloc Unit | 76               | 76        |               | 76          | 1                | 1         |               | 1           |
| LOP_MODIFY_ROW    | LCX_CLUSTERED     | System Table       | 644              | 348       | 296           |             | 5                | 3         | 2             |             |
| LOP_MODIFY_ROW    | LCX_IAM           | T                  | 800              | 800       | 800           |             | 8                | 8         | 8             |             |
| LOP_MODIFY_ROW    | LCX_PFS           | T                  | 11736            | 11736     | 11736         |             | 133              | 133       | 133           |             |
| LOP_MODIFY_ROW    | LCX_PFS           | Unknown Alloc Unit | 92               | 92        | 92            |             | 1                | 1         | 1             |             |
| LOP_SET_BITS      | LCX_GAM           | T                  | 9000             | 9000      | 9000          |             | 125              | 125       | 125           |             |
| LOP_SET_BITS      | LCX_IAM           | T                  | 9000             | 9000      | 9000          |             | 125              | 125       | 125           |             |
| LOP_SET_BITS      | LCX_PFS           | System Table       | 896              | 896       |               |             | 16               | 16        |               |             |
| LOP_SET_BITS      | LCX_PFS           | T                  |                  |           |               | 56000       |                  |           |               | 1000        |
| LOP_SET_BITS      | LCX_SGAM          | Unknown Alloc Unit | 168              | 224       | 168           |             | 3                | 4         | 3             |             |
+-------------------+-------------------+--------------------+------------------+-----------+---------------+-------------+------------------+-----------+---------------+-------------+
| Total             |                   |                    | 36736            | 35552     | 32220         | 8164260     | 456              | 448       | 406           | 2003        |
+-------------------+-------------------+--------------------+------------------+-----------+---------------+-------------+------------------+-----------+---------------+-------------+

O teste foi realizado em um banco de dados com modelo de recuperação total contra uma tabela de 1.000 linhas com uma linha por página. A tabela consome 1.004 páginas no total devido à página de índice raiz e 3 páginas de índice de nível intermediário.

8 dessas páginas são alocações de página única em extensões mistas, com o restante distribuído em 125 extensões uniformes. As 8 desalocações de página única aparecem como as 8 LOP_MODIFY_ROW,LCX_IAMentradas de log. As desalocações de 125 extensões como LOP_SET_BITS LCX_GAM,LCX_IAM. Ambas as operações também requerem uma atualização para a página associada , portanto, as 133 entradas PFScombinadas . LOP_MODIFY_ROW, LCX_PFSEntão, quando a tabela é realmente descartada, os metadados sobre ela precisam ser removidos de várias tabelas do sistema, portanto, as 22 LOP_DELETE_ROWSentradas de log da tabela do sistema (contabilizadas abaixo)

+----------------------+--------------+-------------------+-------------------+
|        Object        | Rows Deleted | Number of Indexes | Delete Operations |
+----------------------+--------------+-------------------+-------------------+
| sys.sysallocunits    |            1 |                 2 |                 2 |
| sys.syscolpars       |            2 |                 2 |                 4 |
| sys.sysidxstats      |            1 |                 2 |                 2 |
| sys.sysiscols        |            1 |                 2 |                 2 |
| sys.sysobjvalues     |            1 |                 1 |                 1 |
| sys.sysrowsets       |            1 |                 1 |                 1 |
| sys.sysrscols        |            2 |                 1 |                 2 |
| sys.sysschobjs       |            2 |                 4 |                 8 |
+----------------------+--------------+-------------------+-------------------+
|                      |              |                   |                22 |
+----------------------+--------------+-------------------+-------------------+

Roteiro completo abaixo

DECLARE @Results TABLE
(
    Testing int NOT NULL,
    Operation nvarchar(31) NOT NULL,
    Context nvarchar(31)  NULL,
    AllocUnitName nvarchar(1000) NULL,
    SumLen int NULL,
    Cnt int NULL
)

DECLARE @I INT = 1

WHILE @I <= 4
BEGIN
IF OBJECT_ID('T','U') IS NULL
     CREATE TABLE T(N INT PRIMARY KEY,Filler char(8000) NULL)

INSERT INTO T(N)
SELECT DISTINCT TOP 1000 number
FROM master..spt_values


CHECKPOINT

DECLARE @allocation_unit_id BIGINT

SELECT @allocation_unit_id = allocation_unit_id
FROM   sys.partitions AS p
       INNER JOIN sys.allocation_units AS a
         ON p.hobt_id = a.container_id
WHERE  p.object_id = object_id('T')  

DECLARE @LSN NVARCHAR(25)
DECLARE @LSN_HEX NVARCHAR(25)

SELECT @LSN = MAX([Current LSN])
FROM fn_dblog(null, null)


SELECT @LSN_HEX=
        CAST(CAST(CONVERT(varbinary,SUBSTRING(@LSN, 1, 8),2) AS INT) AS VARCHAR) + ':' +
        CAST(CAST(CONVERT(varbinary,SUBSTRING(@LSN, 10, 8),2) AS INT) AS VARCHAR) + ':' +
        CAST(CAST(CONVERT(varbinary,SUBSTRING(@LSN, 19, 4),2) AS INT) AS VARCHAR)

  BEGIN TRAN
    IF @I = 1
      BEGIN
          TRUNCATE TABLE T

          DROP TABLE T
      END
    ELSE
      IF @I = 2
        BEGIN
            DROP TABLE T
        END
      ELSE
        IF @I = 3
          BEGIN
              TRUNCATE TABLE T
          END  
      ELSE
        IF @I = 4
          BEGIN
              DELETE FROM T
          END                
  COMMIT

INSERT INTO @Results
SELECT @I,
       CASE
         WHEN GROUPING(Operation) = 1 THEN 'Total'
         ELSE Operation
       END,
       Context,
       CASE
         WHEN AllocUnitId = @allocation_unit_id THEN 'T'
         WHEN AllocUnitName LIKE 'sys.%' THEN 'System Table'
         ELSE AllocUnitName
       END,
       COALESCE(SUM([Log Record Length]), 0) AS [Size in Bytes],
       COUNT(*)                              AS Cnt
FROM   fn_dblog(@LSN_HEX, null) AS D
WHERE  [Current LSN] > @LSN  
GROUP BY GROUPING SETS((Operation, Context,
       CASE
         WHEN AllocUnitId = @allocation_unit_id THEN 'T'
         WHEN AllocUnitName LIKE 'sys.%' THEN 'System Table'
         ELSE AllocUnitName
       END),())


SET @I+=1
END 

SELECT Operation,
       Context,
       AllocUnitName,
       AVG(CASE WHEN Testing = 1 THEN SumLen END) AS [Truncate / Drop Bytes],
       AVG(CASE WHEN Testing = 2 THEN SumLen END) AS [Drop Bytes],
       AVG(CASE WHEN Testing = 3 THEN SumLen END) AS [Truncate Bytes],
       AVG(CASE WHEN Testing = 4 THEN SumLen END) AS [Delete Bytes],
       AVG(CASE WHEN Testing = 1 THEN Cnt END) AS [Truncate / Drop Count],
       AVG(CASE WHEN Testing = 2 THEN Cnt END) AS [Drop Count],
       AVG(CASE WHEN Testing = 3 THEN Cnt END) AS [Truncate Count],
       AVG(CASE WHEN Testing = 4 THEN Cnt END) AS [Delete Count]              
FROM   @Results
GROUP  BY Operation,
          Context,
          AllocUnitName   
ORDER BY Operation, Context,AllocUnitName        

DROP TABLE T

OK, pensei em tentar fazer alguns benchmarks que não dependessem de nenhum "cache quente" para que, esperançosamente, fossem um teste mais realista (também usando o Postgres, para ver se ele corresponde às mesmas características de outras respostas postadas) :

Meus benchmarks usando o postgres 9.3.4 com um banco de dados grande (espero que seja grande o suficiente para não caber no cache da RAM):

Usando este script de banco de dados de teste: https://gist.github.com/rdp/8af84fbb54a430df8fc0

com 10 milhões de linhas:

truncate: 1763ms
drop: 2091ms
truncate + drop: 1763ms (truncate) + 300ms (drop) (2063ms total)
drop + recreate: 2063ms (drop) + 242ms (recreate)

com 100 milhões de linhas:

truncate: 5516ms
truncate + drop: 5592ms
drop: 5680ms (basically, the exact same ballpark)

Então, a partir disso, suponho o seguinte: drop é "quase" tão rápido (ou mais rápido) quanto truncate + drop (pelo menos para versões modernas do Postgres), no entanto, se você planeja também virar e recriar a tabela, você pode bem, continue fazendo um truncate direto, que é mais rápido que um drop+recreate (faz sentido). FWIW.

nota 1: https://stackoverflow.com/questions/11419536/postgresql-truncation-speed/11423886#11423886 (diz que o postgres 9.2 pode ter um truncado mais rápido do que as versões anteriores). Como sempre, faça um benchmark com seu próprio sistema para ver suas características.

nota 2: truncate pode ser revertido no postgres, se estiver em uma transação: http://www.postgresql.org/docs/8.4/static/sql-truncate.html

nota 3: truncar pode, com tabelas pequenas, às vezes ser mais lento que uma exclusão: https://stackoverflow.com/questions/11419536/postgresql-truncation-speed/11423886#11423886

Adicionando alguma perspectiva histórica ...

A eliminação de uma tabela requer a atualização de várias tabelas do sistema, o que normalmente requer fazer essas alterações na tabela do sistema em uma única transação (pense em "começar tran, excluir syscolumns, excluir sysobjects, confirmar").

Também está incluída na 'tabela de descarte' a necessidade de desalocar todas as páginas de dados/índice associadas à tabela.

Muitos, muitos, muitos anos atrás ... o processo de desalocação de espaço foi incluído na transação que também atualizou as tabelas do sistema; o resultado líquido foi que quanto maior o número de páginas alocadas, mais tempo levava para desalocar as referidas páginas, maior o transação (nas tabelas do sistema) foi deixada em aberto e, portanto, uma chance maior de bloquear (nas tabelas do sistema) outros processos tentando criar/descartar tabelas no tempdb (especialmente desagradável com o allpages== bloqueio de nível de página mais antigo e potencial para tabela -nível de escalonamento de bloqueio).

Um método inicial usado (na época) para reduzir a contenção nas tabelas do sistema era reduzir o tempo que os bloqueios eram mantidos nas tabelas do sistema, e uma maneira (relativamente) fácil de fazer isso era desalocar as páginas de dados/índice antes de descartar a mesa.

Embora truncate tablenão desaloque todas as páginas de dados/índice, ele desaloca todas, exceto uma extensão de 8 páginas (dados); outro 'hack' foi descartar todos os índices antes de descartar a tabela (sim, separar txn em sysindexes, mas um txn menor para descartar tabela).

Quando você considera que (novamente, muitos, muitos anos atrás) havia apenas um único banco de dados 'tempdb', e alguns aplicativos faziam uso PESADO desse único banco de dados 'tempdb', quaisquer 'hacks' que pudessem reduzir a contenção nas tabelas do sistema em 'tempdb' foram benéficos; com o tempo, as coisas melhoraram ... vários bancos de dados temporários, bloqueio de nível de linha nas tabelas do sistema, melhores métodos de desalocação, etc.

Enquanto isso, o uso do truncate tablenão faz mal se for deixado no código.

Talvez haja uma razão histórica e temporária. Antes do Postgres 9.3 EVENTS TRIGGER não existe e você não podia "ON DROP" TRIGGER.

Mas a partir do Postgres 8.4 é possível fazer TRIGGER ON TRUNCATE Então talvez algumas pessoas que fariam alguma coisa especial tenham usado o TRIGGER ON TRUNCATEpara simular o ON DROPe para garantir a ativação do gatilho eles fazem TRUNCATE e depois DROP.

Faz sentido fazer TRUNCATE para tabelas que possuem chaves estrangeiras. No entanto, para tabelas temporárias apenas DROP é suficiente

O objetivo do truncateé remover de forma simples e irrevogável tudo na tabela (algumas especificações técnicas baseadas em mecanismos de armazenamento de dados podem diferir um pouco) - pulando registros pesados, etc.

drop tableregistra todas as alterações à medida que as alterações estão sendo feitas. Portanto, para ter um registro mínimo e reduzir a rotatividade inútil do sistema, eu suspeitaria que uma tabela muito grande poderia ser truncada primeiro e depois descartada.

truncatepode ser envolvido em uma transação (que seria a opção mais segura) que, é claro, permitirá reverter a operação.