Dela via


Indexering av data från Azure SQL Database

I den här artikeln får du lära dig hur du konfigurerar en indexerare som importerar innehåll från Azure SQL Database eller en hanterad Azure SQL-instans och gör den sökbar i Azure AI Search.

Den här artikeln kompletterar Skapa en indexerare med information som är specifik för Azure SQL. Den använder Azure Portal- och REST-API:er för att demonstrera ett arbetsflöde i tre delar som är gemensamt för alla indexerare: skapa en datakälla, skapa ett index, skapa en indexerare. Dataextrahering sker när du skickar begäran skapa indexerare.

Den här artikeln innehåller också:

Anmärkning

Datasynkronisering i realtid är inte möjligt med en indexerare. En indexerare kan indexera om tabellen högst var femte minut. Om datauppdateringar behöver återspeglas i indexet tidigare rekommenderar vi att du skickar uppdaterade rader direkt.

Förutsättningar

  • En Azure SQL-databas eller en SQL Managed Instance med en offentlig slutpunkt.

  • En enda tabell eller vy.

    Använd en tabell om dina data är stora eller om du behöver inkrementell indexering med hjälp av SQL:s inbyggda funktioner för ändringsidentifiering (SQL-integrerad ändringsspårning) för att återspegla nya, ändrade och borttagna rader i sökindexet.

    Använd en vy om du behöver konsolidera data från flera tabeller. Stora vyer är inte idealiska för SQL-indexerare. En lösning är att skapa en ny tabell bara för inmatning till ditt Azure AI Search-index. Om du väljer att gå med en vy kan du använda Högvattenmärke för ändringsidentifiering, men du måste använda en tillfällig lösning för borttagningsidentifiering.

  • Primärnyckeln måste vara envärdesnyckel. I en tabell måste den också vara icke-klustrad för fullständig SQL-integrerad ändringsspårning.

  • Läsbehörigheter. Azure AI Search stöder SQL Server-autentisering, där användarnamnet och lösenordet anges i anslutningssträngen. Du kan också konfigurera en hanterad identitet och använda Azure-roller med medlemskap i SQL Server-deltagare eller SQL DB-deltagarroller .

Om du vill gå igenom exemplen i den här artikeln behöver du Azure Portal eller en REST-klient. Om du använder Azure-portalen kontrollerar du att åtkomsten till alla offentliga nätverk är aktiverad i Azure SQL-brandväggen och att klienten har åtkomst via en inkommande regel. För en REST-klient som körs lokalt konfigurerar du SQL Server-brandväggen så att inkommande åtkomst tillåts från enhetens IP-adress. Andra metoder för att skapa en Azure SQL-indexerare är Azure SDK:er.

Prova med exempeldata

Använd de här anvisningarna för att skapa och läsa in en tabell i Azure SQL Database i testsyfte.

  1. Ladda ned hotels-azure-sql.sql från GitHub för att skapa en tabell i Azure SQL Database som innehåller en delmängd av datauppsättningen exempelhotell.

  2. Logga in på Azure-portalen och skapa en Azure SQL-databas och databasserver. Överväg att konfigurera både SQL Server-autentisering och Microsoft Entra-ID-autentisering. Om du inte har behörighet att konfigurera roller i Azure kan du använda SQL-autentisering som en lösning.

  3. Konfigurera serverbrandväggen för alla inkommande begäranden från din lokala enhet.

  4. I Din Azure SQL-databas väljer du Frågeredigeraren (förhandsversion) och väljer sedan Ny fråga.

  5. Klistra in och kör sedan T-SQL-skriptet som skapar hotell-tabellen. En icke-klustrad primärnyckel är ett krav för SQL-integrerad ändringsspårning.

    CREATE TABLE tbl_hotels
     (
         Id TINYINT PRIMARY KEY NONCLUSTERED,
         Modified DateTime NULL DEFAULT '0000-00-00 00:00:00',
         IsDeleted TINYINT,
         HotelName VARCHAR(40),
         Category VARCHAR(20),
         City VARCHAR(30),
         State VARCHAR(4),
         Description VARCHAR(500)
     );
    
  6. Klistra in och kör sedan T-SQL-skriptet som infogar dataposter.

     -- Insert rows
     INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (1, CURRENT_TIMESTAMP, 0,  'Stay-Kay City Hotel', 'Boutique', 'New York', 'NY', 'This classic hotel is fully-refurbished and ideally located on the main commercial artery of the city in the heart of New York. A few minutes away is Times Square and the historic centre of the city, as well as other places of interest that make New York one of Americas most attractive and cosmopolitan cities.');
     INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (10, CURRENT_TIMESTAMP, 0, 'Countryside Hotel', 'Extended-Stay', 'Durham', 'NC', 'Save up to 50% off traditional hotels. Free WiFi, great location near downtown, full kitchen, washer & dryer, 24\/7 support, bowling alley, fitness center and more.');
     INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (11, CURRENT_TIMESTAMP, 0, 'Royal Cottage Resort', 'Extended-Stay', 'Bothell', 'WA', 'Your home away from home. Brand new fully equipped premium rooms, fast WiFi, full kitchen, washer & dryer, fitness center. Inner courtyard includes water features and outdoor seating. All units include fireplaces and small outdoor balconies. Pets accepted.');
     INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (12, CURRENT_TIMESTAMP, 0, 'Winter Panorama Resort', 'Resort and Spa', 'Wilsonville', 'OR', 'Plenty of great skiing, outdoor ice skating, sleigh rides, tubing and snow biking. Yoga, group exercise classes and outdoor hockey are available year-round, plus numerous options for shopping as well as great spa services. Newly-renovated with large rooms, free 24-hr airport shuttle & a new restaurant. Rooms\/suites offer mini-fridges & 49-inch HDTVs.');
     INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (13, CURRENT_TIMESTAMP, 0, 'Luxury Lion Resort', 'Luxury', 'St. Louis', 'MO', 'Unmatched Luxury. Visit our downtown hotel to indulge in luxury accommodations. Moments from the stadium and transportation hubs, we feature the best in convenience and comfort.');
     INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (14, CURRENT_TIMESTAMP, 0, 'Twin Vortex Hotel', 'Luxury', 'Dallas', 'TX', 'New experience in the making. Be the first to experience the luxury of the Twin Vortex. Reserve one of our newly-renovated guest rooms today.');
     INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (15, CURRENT_TIMESTAMP, 0, 'By the Market Hotel', 'Budget', 'New York', 'NY', 'Book now and Save up to 30%. Central location. Walking distance from the Empire State Building & Times Square, in the Chelsea neighborhood. Brand new rooms. Impeccable service.');
     INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (16, CURRENT_TIMESTAMP, 0, 'Double Sanctuary Resort', 'Resort and Spa', 'Seattle', 'WA', '5 Star Luxury Hotel - Biggest Rooms in the city. #1 Hotel in the area listed by Traveler magazine. Free WiFi, Flexible check in\/out, Fitness Center & espresso in room.');
     INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (17, CURRENT_TIMESTAMP, 0, 'City Skyline Antiquity Hotel', 'Boutique', 'New York', 'NY', 'In vogue since 1888, the Antiquity Hotel takes you back to bygone era. From the crystal chandeliers that adorn the Green Room, to the arched ceilings of the Grand Hall, the elegance of old New York beckons. Elevate Your Experience. Upgrade to a premiere city skyline view for less, where old world charm combines with dramatic views of the city, local cathedral and midtown.');
     INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (18, CURRENT_TIMESTAMP, 0, 'Ocean Water Resort & Spa', 'Luxury', 'Tampa', 'FL', 'New Luxury Hotel for the vacation of a lifetime. Bay views from every room, location near the pier, rooftop pool, waterfront dining & more.');
     INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (19, CURRENT_TIMESTAMP, 0, 'Economy Universe Motel', 'Budget', 'Redmond', 'WA', 'Local, family-run hotel in bustling downtown Redmond. We are a pet-friendly establishment, near expansive Marymoor park, haven to pet owners, joggers, and sports enthusiasts. Close to the highway and just a short drive away from major cities.');
     INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (20, CURRENT_TIMESTAMP, 0, 'Delete Me Hotel', 'Unknown', 'Nowhere', 'XX', 'Test-case row for change detection and delete detection . For change detection, modify any value, and then re-run the indexer. For soft-delete, change IsDelete from zero to a one, and then re-run the indexer.');
    
    
  7. Kör en sökfråga för att bekräfta uppladdningen.

    SELECT Description FROM tbl_hotels;
    

    Du bör se resultat som liknar följande skärmbild.

    Skärmbild av frågeresultat som visar beskrivningsfältet.

Fältet Beskrivning innehåller det mest utförliga innehållet. Du bör rikta in dig på det här fältet för fulltextsökning och valfri vektorisering.

Nu när du har en databastabell kan du använda Azure-portalen, REST-klienten eller en Azure SDK för att indexera dina data.

Tips/Råd

En annan resurs som tillhandahåller exempelinnehåll och kod finns i Azure-Samples/SQL-AI-samples.

Konfigurera indexer-pipelinen

I det här steget anger du datakällan, indexet och indexeraren.

  1. Kontrollera att SQL-databasen är aktiv och inte pausad på grund av inaktivitet. I Azure-portalen går du till databasserversidan och kontrollerar att databasstatusen är online. Du kan köra en fråga i valfri tabell för att aktivera databasen.

    Skärmbild av databasens statussida i Azure-portalen.

  2. Kontrollera att du har en tabell eller vy som uppfyller kraven för indexerare och ändringsidentifiering.

    Först kan du bara hämta från en enda tabell eller vy. Vi rekommenderar tabeller eftersom de stöder EN SQL-princip för integrerad ändringsspårning som identifierar nya, uppdaterade och borttagna rader. En högvattenmärkesprincip stödjer inte borttagning av rader och är svårare att genomföra.

    För det andra måste den primära nyckeln vara ett enda värde (sammansatta nycklar stöds inte) och icke-klustrerad.

  3. Växla till söktjänsten och skapa en datakälla. UnderSökhanteringsdatakällor> väljer du Lägg till datakälla:

    1. För datakällans typ väljer du Azure SQL Database.
    2. Ange ett namn för datakällans objekt i Azure AI Search.
    3. Använd listrutorna för att välja prenumeration, kontotyp, server, databas, tabell eller vy, schema och tabellnamn.
    4. För ändringsspårning rekommenderar vi SQL Integrated Change Tracking Policy.
    5. För autentisering rekommenderar vi att du ansluter med en hanterad identitet. Din söktjänst måste ha rollmedlemskap för SQL Server-deltagare eller SQL DB-deltagare i databasen.
    6. Välj Skapa för att skapa datakällan.

    Skärmbild av sidan för att skapa datakällor i Azure-portalen.

  4. Använd en importguide för att skapa indexet och indexeraren.

    1. På sidan Översikt väljer du Importera data eller Importera data (ny).

    2. Välj den datakälla som du nyss skapade.

    3. Hoppa över steget för att lägga till AI-berikanden.

    4. Ge indexet ett namn, ange nyckeln till primärnyckeln i tabellen, tilldela alla fält som Hämtningsbara och sökbara, samt lägg till Filterable och Sortable för korta strängar eller numeriska värden.

    5. Namnge indexeraren och slutför guiden för att skapa nödvändiga objekt.

Kontrollera status för indexerare

Om du vill övervaka indexerarens status och körningshistorik kontrollerar du indexerarens körningshistorik i Azure-portalen eller skickar en REST API-begäran för Get Indexer Status

  1. Öppna Indexerare>.

  2. Välj en indexerare för att komma åt konfigurations- och körningshistoriken.

  3. Välj ett specifikt indexeringsjobb för att visa information, varningar och fel.

Körningshistoriken innehåller upp till 50 av de senast slutförda körningarna, som sorteras i omvänd kronologisk ordning så att den senaste körningen kommer först.

Indexera nya, ändrade och borttagna rader

Om din SQL-databas stöder ändringsspårning kan en sökindexerare bara hämta det nya och uppdaterade innehållet vid efterföljande indexerarekörningar.

Om du vill aktivera inkrementell indexering anger du egenskapen "dataChangeDetectionPolicy" i datakälldefinitionen. Den här egenskapen talar om för indexeraren vilken mekanism för ändringsspårning som används i tabellen eller vyn.

För Azure SQL-indexerare finns det två principer för ändringsidentifiering:

  • "SqlIntegratedChangeTrackingPolicy" (gäller endast tabeller)

  • "HighWaterMarkChangeDetectionPolicy" (fungerar för vyer)

SQL-integrerad ändringsspårningsprincip

Vi rekommenderar att du använder "SqlIntegratedChangeTrackingPolicy" för dess effektivitet och dess förmåga att identifiera borttagna rader.

Databaskrav:

  • Azure SQL Database eller SQL Managed Instance. SQL Server 2016 eller senare om du använder en virtuell Azure-dator.
  • Databasen måste ha aktiverat ändringsspårning
  • Endast tabeller (inga vyer).
  • Tabeller kan inte grupperas. För att uppfylla detta krav släpper du det klustrade indexet och återskapar det som icke-grupperat index. Den här lösningen försämrar ofta prestanda. Att duplicera innehåll i en andra tabell som är dedikerad till indexeringsbearbetning kan vara en användbar åtgärd.
  • Tabeller kan inte vara tomma. Om du använder TRUNCATE TABLE för att rensa rader, kommer en återställning och omkörning av indexeraren inte att ta bort de motsvarande sökdokumenten. För att ta bort föräldralösa sökdokument måste du indexera dem med en raderingsåtgärd.
  • Primärnyckel får inte vara en sammansatt nyckel (som innehåller mer än en kolumn).
  • Primärnyckeln måste vara icke-klustrerad om du vill ha upptäckt av borttagning.

Principer för ändringsidentifiering läggs till i datakällans definitioner. Om du vill använda den här principen redigerar du datakällans definition i Azure-portalen eller använder REST för att uppdatera datakällan så här:

POST https://myservice.search.windows.net/datasources?api-version=2025-09-01
Content-Type: application/json
api-key: admin-key
    {
        "name" : "myazuresqldatasource",
        "type" : "azuresql",
        "credentials" : { "connectionString" : "connection string" },
        "container" : { "name" : "table name" },
        "dataChangeDetectionPolicy" : {
            "@odata.type" : "#Microsoft.Azure.Search.SqlIntegratedChangeTrackingPolicy"
        }
    }

När du använder EN SQL-princip för integrerad ändringsspårning ska du inte ange en separat princip för identifiering av databorttagning. Sql-principen för integrerad ändringsspårning har inbyggt stöd för att identifiera borttagna rader. Men för att de borttagna raderna ska kunna identifieras automatiskt måste dokumentnyckeln i sökindexet vara samma som primärnyckeln i SQL-tabellen och den primära nyckeln måste vara icke-klustrad.

Strategi för upptäckt av förändringar vid högvattenmärkesvärde

Den här principen för ändringsidentifiering förlitar sig på en kolumn med högvattenmärke i tabellen eller vyn som fångar upp den version eller tidpunkt då en rad senast uppdaterades. Om du använder en vy måste du använda en princip för högvattenmärke.

Högvattenmärkeskolumnen måste uppfylla följande krav:

  • Alla infogningar anger ett värde för kolumnen.
  • Alla uppdateringar av ett objekt ändrar också värdet i kolumnen.
  • Värdet för den här kolumnen ökar med varje infogning eller uppdatering.
  • Frågor med följande WHERE- och ORDER BY-satser kan köras effektivt: WHERE [High Water Mark Column] > [Current High Water Mark Value] ORDER BY [High Water Mark Column]

Anmärkning

Vi rekommenderar starkt att du använder datatypen rowversion för högvattenmärkeskolumnen. Om någon annan datatyp används garanteras inte ändringsspårning att samla in alla ändringar i närvaro av transaktioner som körs samtidigt med en indexerarfråga. När du använder rowversion i en konfiguration med skrivskyddade repliker måste du peka indexeraren på den primära repliken. Endast en primär replik kan användas för datasynkroniseringsscenarier.

Principer för ändringsidentifiering läggs till i datakällans definitioner. Om du vill använda den här principen skapar eller uppdaterar du datakällan så här:

POST https://myservice.search.windows.net/datasources?api-version=2025-09-01
Content-Type: application/json
api-key: admin-key
    {
        "name" : "myazuresqldatasource",
        "type" : "azuresql",
        "credentials" : { "connectionString" : "connection string" },
        "container" : { "name" : "table or view name" },
        "dataChangeDetectionPolicy" : {
            "@odata.type" : "#Microsoft.Azure.Search.HighWaterMarkChangeDetectionPolicy",
            "highWaterMarkColumnName" : "[a rowversion or last_updated column name]"
        }
    }

Anmärkning

Om källtabellen inte har ett index på högvattenmärkeskolumnen kan frågor som används av SQL-indexeraren överskrida tidsgränsen. I synnerhet kräver ORDER BY [High Water Mark Column]-satsen ett index för att köras effektivt när tabellen innehåller många rader.

konverteraHögvattenmärkeTillRadversion

Om du använder en radversionsdatatyp för kolumnen av typen "high water mark", bör du överväga att ange egenskapen convertHighWaterMarkToRowVersion i indexerinställningarna. Om du ställer in den här egenskapen på sant resulterar det i följande beteenden:

  • Använder datatypen rowversion för kolumnen högvattenmärke i indexerarens SQL-fråga. Om du använder rätt datatyp förbättras indexerarens frågeprestanda.

  • Subtraherar en från värdet för rowversion innan indexeringsfrågan körs. Vyer med en-till-många-kopplingar kan ha rader med dubbla radversionsvärden. Genom att subtrahera en ser du till att indexerarfrågan inte missar dessa rader.

Om du vill aktivera den här egenskapen skapar eller uppdaterar du indexeraren med följande konfiguration:

    {
      ... other indexer definition properties
     "parameters" : {
            "configuration" : { "convertHighWaterMarkToRowVersion" : true } }
    }

förfråganTidsgräns

Om du får timeout-fel anger du queryTimeout indexerarens konfigurationsinställning till ett värde som är högre än standardvärdet på 5 minuters timeout. Om du till exempel vill ange tidsgränsen till 10 minuter skapar eller uppdaterar du indexeraren med följande konfiguration:

    {
      ... other indexer definition properties
     "parameters" : {
            "configuration" : { "queryTimeout" : "00:10:00" } }
    }

inaktiveraSorteraEfterHögvattenmärkesKolumn

Du kan också inaktivera ORDER BY [High Water Mark Column] satsen. Detta rekommenderas dock inte eftersom om indexerarens körning avbryts av ett fel måste indexeraren bearbeta alla rader igen om den körs senare, även om indexeraren redan har bearbetat nästan alla rader vid den tidpunkt då den avbröts. Om du vill inaktivera ORDER BY -satsen använder du disableOrderByHighWaterMarkColumn inställningen i indexerardefinitionen:

    {
     ... other indexer definition properties
     "parameters" : {
            "configuration" : { "disableOrderByHighWaterMarkColumn" : true } }
    }

Princip för detektering av borttagning av kolumner med mjuk borttagning

När rader tas bort från källtabellen vill du förmodligen även ta bort dessa rader från sökindexet. Om du använder sql-principen för integrerad ändringsspårning tas detta hand om åt dig. Principen för ändringsspårning med högvattenmärke hjälper dig dock inte med borttagna rader. Vad bör jag göra?

Om raderna tas bort fysiskt från tabellen kan Azure AI Search inte härleda förekomsten av poster som inte längre finns. Du kan dock använda metoden "mjuk borttagning" för att logiskt ta bort rader utan att ta bort dem från tabellen. Lägg till en kolumn i tabellen eller vyn och markera rader som borttagna med den kolumnen.

När du använder metoden för mjuk borttagning kan du ange principen för mjuk borttagning på följande sätt när du skapar eller uppdaterar datakällan:

    {
        …,
        "dataDeletionDetectionPolicy" : {
           "@odata.type" : "#Microsoft.Azure.Search.SoftDeleteColumnDeletionDetectionPolicy",
           "softDeleteColumnName" : "[a column name]",
           "softDeleteMarkerValue" : "[the value that indicates that a row is deleted]"
        }
    }

SoftDeleteMarkerValue måste vara en sträng i JSON-representationen av datakällan. Använd strängrepresentationen av ditt faktiska värde. Om du till exempel har en heltalskolumn där borttagna rader har markerats med värdet 1 använder du "1". Om du har en BIT-kolumn där borttagna rader har markerats med det booleska 'true'-värdet, använd strängliteralen "True" eller "true", det spelar ingen roll.

Om du konfigurerar en princip för mjuk borttagning från Azure-portalen ska du inte lägga till citattecken runt markörvärdet för mjuk borttagning. Fältinnehållet tolkas redan som en sträng och översätts automatiskt till en JSON-sträng åt dig. I föregående exempel skriver 1du helt enkelt , True eller true i Azure-portalens fält.

FAQ

F: Kan jag indexera "Always Encrypted"-kolumner?

Nej, Always Encrypted-kolumner stöds för närvarande inte av Azure AI Search-indexerare.

F: Kan jag använda Azure SQL-indexerare med SQL-databaser som körs på virtuella IaaS-datorer i Azure?

Ja. Du måste dock tillåta att söktjänsten ansluter till databasen. Mer information finns i Konfigurera en anslutning från en Azure AI Search-indexerare till SQL Server på en virtuell Azure-dator.

F: Kan jag använda Azure SQL-indexerare med SQL-databaser som körs lokalt?

Inte direkt. Vi rekommenderar eller stöder inte en direkt anslutning, eftersom det skulle kräva att du öppnar dina databaser för Internettrafik. Kunderna har lyckats med det här scenariot med hjälp av integrationstekniker som Azure Data Factory. Mer information finns i Skicka data till ett Azure AI Search-index med Azure Data Factory.

F: Kan jag använda en sekundär replik i ett redundanskluster som datakälla?

Det beror på. För fullständig indexering av en tabell eller vy kan en sekundär replik användas.

För inkrementell indexering stöder Azure AI Search två principer för ändringsidentifiering: SQL-integrerad ändringsspårning och högvattenmärke.

På skrivskyddade repliker stöder SQL Database inte integrerad ändringsspårning. Därför måste du använda High Water Mark-principen.

Vår standardrekommendering är att använda datatypen rowversion för högvattenmärkeskolumnen. Men om du använder rowversion används MIN_ACTIVE_ROWVERSION funktionen, som inte stöds på skrivskyddade repliker. Därför måste du peka indexeraren på en primär replik om du använder rowversion.

Om du försöker använda rowversion på en skrivskyddad replik får du följande fel:

"Användning av en radversionskolumn för ändringsspårning stöds inte på sekundära (skrivskyddade) tillgänglighetsrepliker. Uppdatera datakällan och ange en anslutning till den primära tillgänglighetsrepliken. Den aktuella databasegenskapen "Uppdateringsbarhet" är "READ_ONLY".

F: Kan jag använda en alternativ kolumn som inte är av rowversion-typ för ändringsspårning med högvattenmarkör?

Det rekommenderas inte. Endast rowversion tillåter tillförlitlig datasynkronisering. Beroende på programlogik kan det dock vara säkert om:

  • Du kan se till att det inte finns några utestående transaktioner i tabellen som indexeras när indexeraren körs (till exempel sker alla tabelluppdateringar som en batch enligt ett schema och azure AI Search-indexerarens schema anges för att undvika överlappning med tabelluppdateringsschemat).

  • Du gör regelbundet en fullständig omindex för att hämta eventuella missade rader.