This is a read-only copy of the MariaDB Knowledgebase generated on 2024-12-22. For the latest, interactive version please visit https://mariadb.com/kb/.

Le clausole HIGH_PRIORITY e LOW_PRIORITY

InnoDB/XtraDB usa il locking a livello di riga per garantire l'integrità dei dati. Tuttavia alcuni Storage Engine (come MEMORY, MyISAM, Aria, MERGE) acquisiscono i lock sull'intera tabella per evitare i conflitti. Questi Storage Engine usano due code distinte per ricordare le istruzioni in attesa: una per le SELECT e l'altra per i comandi di scrittura (INSERT, DELETE, UPDATE). Per default, quest'ultima ha una priorità più elevata.

Per dare alle operazioni di scrittura una priorità più bassa, è possibile impostare la variabile low_priority_updates a ON. Questa opzione esiste sia a livello globale sia a livello di sessione, e può essere impostata sia all'avvio sia con l'istruzione SET.

Quando le istruzioni di scrittura impostano troppi lock a livello di tabella, alcune SELECT in attesa vengono eseguite. Il numero massimo dei lock in scrittura che possono essere acquisiti prima che ciò accada è determinato dalla variabile max_write_lock_count, che è dinamica.

Se le istruzioni di scrittura hanno una priorità più alta (come da default), la priorità dei singoli comandi (INSERT, REPLACE, UPDATE, DELETE) può essere abbassata attraverso l'attributo LOW_PRIORITY, e la priorità delle istruzioni SELECT può essere elevata tramite l'attributo HIGH_PRIORITY. Inoltre, LOCK TABLES supporta un attributo LOW_PRIORITY per i lock in scrittura.

Se le istruzioni di lettura hanno una priorità più alta, la priorità di una INSERT può essere elevata con l'attributo HIGH_PRIORITY. Tuttavia la priorità degli altri comandi non può essere elevata individualmente.

L'uso di LOW_PRIORITY o HIGH_PRIORITY per le INSERT impedisce l'uso delle INSERT concorrenti.

Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.