Det finns en liten prestandaträff på infogar, uppdateringar och borttagningar eftersom FK måste kontrolleras. För en individuell post skulle detta normalt vara så litet att det inte märks om du inte börjar ha ett löjligt antal FK:er associerade med tabellen (det tar helt klart längre tid att kontrollera 100 andra tabeller än 2). Detta är bra och inte dåligt eftersom databaser utan integritet är opålitliga och därmed värdelösa. Du bör inte byta integritet mot snabbhet. Den prestationsträffen kompenseras vanligtvis av den bättre förmågan att optimera genomförandeplaner.
Vi har en medelstor databas med cirka 9 miljoner poster och FK:er överallt där de borde vara och märker sällan en prestandaträff (förutom på ett dåligt designat bord som har långt över 100 främmande nycklar, det är lite långsamt att ta bort poster från detta som allt måste kontrolleras). Nästan varje dba jag känner till som hanterar stora databaser i terabytestorlek och ett verkligt behov av hög prestanda på stora datamängder insisterar på begränsningar för främmande nyckel eftersom integritet är nyckeln till vilken databas som helst. Om personer med terabyte-stora databaser har råd med den mycket lilla prestandaträffen, så kan du också.
FK:er indexeras inte automatiskt och om de inte indexeras kan detta orsaka prestandaproblem.
Ärligt talat skulle jag ta en kopia av din databas, lägga till korrekt indexerade FKs och visa tidsskillnaden för att infoga, ta bort, uppdatera och välja från dessa tabeller i jämförelse med samma från din databas utan FKs. Visa att du inte kommer att orsaka en prestationssuccé. Visa sedan resultaten av frågor som visar föräldralösa poster som inte längre har någon betydelse eftersom PK de är relaterade till inte längre existerar. Det är särskilt effektivt att visa detta för tabeller som innehåller finansiell information ("Vi har 2700 beställningar som vi inte kan koppla till en kund" kommer att få ledningen att sätta sig upp och lägga märke till det).