SharePoint search is content-bases and depends on content location. This means that random page, outside the designated location, won’t be returned from the content-scoped search.

SharePoint functionality is build on the top of SQL Server and has a tight cohesion with SQL Tables. Any user’s actions on the SharePoint site lead to the data entries manipulations across several tables. 
Unfortunately, SharePoint implemented in the way to have few large tables rather then several small tables, and it stores a lot of contents in one single table. Such approach has a side-effect in table locks, which might hinder the performance of SharePoint sites if you are not aware about such table-centric design

SharePoint provides different levels of permissions, from the “Full Access” to “Limited Access”. Last one is not documented clearly and designed to cover some side-effects of item’s hierarchy.

SharePoint content databases grow very rapidly when used in document imaging system or in file share replacement scenarios. With this in mind it is important to consider growth and overhead factors when determining how much content will eventually be stored in a given content database.

Steve Sheppard published nice recommendation regarding optimizing the MOSS Cache performance and how to measure the performance.

The main role of the SSP is to serve as the provider of key centralized services to consuming sites and portals. It was designed with isolation in mind that Web Application Web Application is working with the single SSP only, so that an organization would have a single SSP from which all of its sites could consume enterprise-level services.

People Picker is a nice feature of SharePoint which allows search for a user/group when assigning permissions for example. But it has one issue - it selects the accounts and groups which are “disabled” by default. It's probably what you don't expect to be selected when you configure permissions, because it creates potential security breach

Instead of resetting IIS to clean SharePoint cache the recommended solution is to reset application pools. This is preferable for the production boxes, when you have several sites on your box and you don’t want that all application were affected by IIS reset.

When you install or re-configure SharePoint, one of the steps requests you to specify the details for the application pool and assigning the user account. The trick is the format of the user name you need to specify in ApplicationPoolUserName field - either <domain/user> or just <user>.

Web Application settings supersede what located below, so, all permissions which are set at Web Application level, “Central Administration > Application Management > User Permissions for Web Application” will override the Site level permissions.

The recommended Windows environment which offers the best performance for SharePoint is to have 64-bit servers. Such an environment provides significantly larger address space than 32-bit one; more room for SharePoint assemblies, CLR/Native APIs, Network Stack, IIS/ASP.NET and other components hosted in their respective tiers.

Very often, depending on your infrastructure, URL of a web request received by IIS is not the same URL that the end user entered. This happens in reverse proxy publishing and load balancing scenarios. So, SharePoint needs a way to handle such URLs and return you right sites.