Is connection string's default database used if queries are run against other databases?

Let's say I have an app that uses this connection string to connect to a SQL Server using "DB1" as the default database (a.k.a. initial catalog):

Server=myServerAddress; Database=DB1; User Id=myUsername; Password=myPassword;

But all queries executed through this connection target other databases, never DB1. (Example: SELECT * FROM DB2.dbo.Table1)

Can/will DB1 possibly be used for anything, even though it is not referenced in any queries? I'd like to hear about all possibilities no matter how obscure. (For example, could there be differences in options, cursors, table locking, query performance...?)

I would assume not, except that today I saw strange performance issues with DB1 that are making me second guess my assumption. It could be a red herring but regardless I'd like to make sure I fully understand the role of the default database / initial catalog.

Different performance of the same query typically indicates different execution plans. The database context generally won't yield different plans (and performance) but there are some cases where it could.

The default collation of the current database context determines the collation of literals and parameters. Below is an example that shows a slightly different execution plan when the query differs only by database context:

CREATE DATABASE TestDatabase
    COLLATE Latin1_General_CI_AS;
GO
CREATE DATABASE TestDatabase_SC
    COLLATE Latin1_General_100_CI_AS_SC;
GO

USE TestDatabase;
GO

CREATE TABLE dbo.TestTable(
    Col1 varchar(10) CONSTRAINT PK_TestTable PRIMARY KEY
    );
INSERT INTO dbo.TestTable VALUES('A');
GO

--query plan in TestDatabase context shows seek predicate: Seek Keys[1]: Prefix: [TestDatabase].[dbo].[TestTable].Col1 = Scalar Operator([@1])
SELECT Col1 FROM TestDatabase.dbo.TestTable WHERE col1 = 'A';
GO

USE TestDatabase_SC;
GO

--query plan in TestDatabase_SC context shows seek predicate: Seek Keys[1]: Prefix: [TestDatabase].[dbo].[TestTable].Col1 = Scalar Operator(CONVERT_IMPLICIT(varchar(8000),[@1],0))
SELECT Col1 FROM TestDatabase.dbo.TestTable WHERE col1 = 'A';
GO

I wouldn't expect a significant performance difference here because SQL Server coerces a sargable expression even though the literal and column data types differ.

The current database context also determines SET options used when not explicitly set by the client API or SET statement. This may result in different execution plans, especially for legacy APIs.

StackExchange Database Administrators Q#129194, answer score: 4